edmundhuber
Paradromics is building a high bandwidth brain-machine interface for clinical use. The implant we built is restoring function to patients by streaming out neural data from specific brain regions in real time, which we convert to e.g. speech using machine learning. Check out our recent article in the NYT: https://archive.ph/C6CRb .
We're looking for help in further developing and hardening our embedded Linux components, which work in tandem with FPGAs and our custom ASICs to read out neural data. Some of the ongoing efforts are: HIL testing on real devices, integrating new sensor ASICs, maintaining our Yocto build system, exploratory work on prototypes, improving our clinical UX, and improving the core code that receives and massages data. The code is largely written in Rust with a little Typescript, (and bash, and bitbake recipes, etc).
You'll be expected to have experience constructing reliable and understandable software in Linux, and some level of experience in building and interacting with embedded hardware. Rust experience is ideal but not necessary. We're not looking for a specific number of YoE, but for motivated and hungry engineers who want to push the frontier of brain-machine interfaces.
To apply visit https://paradromicsinc.applytojob.com/apply/u5hXN4N9ID/Embed... or email your resume and a little about yourself to me, [email protected] . I'll be glad to hear from you!
Paradromics is building a high bandwidth brain-machine interface for clinical use. The implant we built is restoring function to patients by streaming out neural data from specific brain regions in real time, which we convert to e.g. speech using machine learning. Check out our recent article in the NYT: https://archive.ph/C6CRb .
We're looking for help in further developing and hardening our embedded Linux components, which work in tandem with FPGAs and our custom ASICs to read out neural data. Some of the ongoing efforts are: HIL testing on real devices, integrating new sensor ASICs, maintaining our Yocto build system, exploratory work on prototypes, improving our clinical UX, and improving the core code that receives and massages data. The code is largely written in Rust with a little Typescript, (and bash, and bitbake recipes, etc).
You'll be expected to have experience constructing reliable and understandable software in Linux, and some level of experience in building and interacting with embedded hardware. Rust experience is ideal but not necessary. We're not looking for a specific number of YoE, but for motivated and hungry engineers who want to push the frontier of brain-machine interfaces.
To apply visit https://paradromicsinc.applytojob.com/apply/u5hXN4N9ID/Embed... or email your resume and a little about yourself to me, [email protected] . I'll be glad to hear from you!
To most people (and BI?) it will mean "taxi, takeoff, navigating/obstacle avoidance, landing". To the extent that driving a car isn't "what you see is what you get", flight is much worse.
In the simplest case of flight, you are in cruise (neither takeoff nor landing), and depending on what kind of airspace you're in you may need to: * listen to ATC for commands, and advise them of what you're doing, * avoid weather, * look out for traffic, * watch your gauges, * stay on a heading, altitude, and generally fly the plane. (This part is routinely done with autopilot.)
In short, if it seems easier, it's because pilots make it look so casual.
A thing they teach pilots is: "Aviate, Navigate, Communicate". This is the basic priorities for your attention. If you're pointed at terrain your priority is to fix that first. The point of autopilot today is to free you (to some extent) of that first responsibility, especially during routine parts of flight, so that you can do the other things. Airbus is looking for more things to automate to let pilots do more strategic thinking in general.
Contrast this with a car, which is probably more in line with what BI is thinking. The kinetic energies are much lower, there's no need to communicate, the rules for driving are pretty straightforward (get to where you want to be, without hitting other people, while respecting traffic lights and speed limits), and to top it all off, if the AI feels that it's in over its head than the car can just stop whenever and everyone can climb out of the vehicle.
Airbus has an "innovation" (R&D) department and they're looking into more ways to have computers do the routine parts of flight.
Airbus's materials (linked) do mention "self-piloting", but I can't imagine that they are thinking of the scale as BusinessInsider is when they write "self-flying". No one's proposing getting rid of pilots, having a computer fly a plane completely would be insanity.
The Air France 447 accident demonstrated to me that Airbus hadn't really thought things through either. Pilots entered conflicting inputs and the plane averaged them out instead of giving (good, actionable) feedback.
Side question: is fly-by-wire an obviously good idea for passenger airplanes? It's ubiquitous in e.g. fighter jets because of the inherent aerodynamic instability of those platforms, making them hard or impossible ("Hopeless diamond") to fly without computer assistance. Passenger jets have different goals and are built to have stable flight -- the plane wants to fly level. My takeaway from Air France 447 was that I want more Boeing-style (linked, mechanical) controls in passenger airplanes than I want fly-by-wire. Am I off base?
The other thing that's helped me is realizing that anything worthwhile is hard. If you want to stick with a project until it's done, you're going to get bored, you're going to run into roadblocks, and you want to cultivate a sense of "this is what I want to do, and that is just a temporary issue that I will work through".
Last thing that's helped me is finding a support group. I use irc, specifically I hang out on irc.darwin.network (shameless plug, I kinda co-run it), there I can chat with people about what I'm working on, they can ask cool questions, etc, keeps the juices flowing and reminds me why a project is worth sticking to.
Meraki makes easy-to-manage cloud-connected APs, cameras, security devices, cellular gateways, (more to come!).
I'm looking for engineers who are comfortable in the kernel and device drivers, and who have a passion for making complete and stable products. Drop me a line at [email protected] if you're interested!
You need to get (particularly, senior) engineers to buy into the mindset of documenting everything and making the documentation the first place to look (not after all else fails). Leads should hold be held accountable for their docs meeting some standard of "this is a useful doc".
If I were in your shoes I'd get senior engineers in a room and be honest with them about the situation. You're going to need them to do work that they might not be naturally inclined to do, or work that might not seem like a "productive" use of time. You might want to get them to agree on what a good doc looks like (the standard), and what things need to be documented. Maybe take a whole day to do this, with snacks and coffee. Good luck!
One reason I can think of this happening is that in order for one's brain to focus on just the parts of the CR that matter, stylistic oddities need to be sorted out. Ideally after some time, a reviewee would stop opening PRs that contradict the basic stylistic standards that the group adheres to (and thus stop wasting everyone's time). Ideally there would also be a linter to get everyone to that point as quickly as possible.
Imagine if you were running an assembly line, and every person in every shift did their welds significantly differently. It would be a waste of time for the inspection workers to have to continuously remind everyone that it's hard to check quality on a variety of different welding methods, rather than just one or two. It would be a better use of everyone's time to just agree on what kinds of welds are acceptable.
In my (and others', from reading other comments) experience, it is pretty unrealistic to swoop in and fix everything at once. You need to establish what you are being asked to do, and then make a reasonable step by step plan. Changing attitudes about software development is very difficult and you need to have a plan.