As long as software folks don’t bring their shenanigans (agile/scum (ahmm scrum) approach, daily stand up, ticket based management, ship products within 2 weeks, among others) into the robotics/engineering world, you are welcome. I have seen many cases of software “project or engineering managers” ruin a whole department because they were trying to force such stupid approaches, it’s always ironic seeing some are trying to force agile for example even though the whole idea of agile is being..agile.
Getting into robotics as a software engineer
71–80 of 105 posts
Re: Getting into robotics as a software engineer
#72Earlier quoted context omitted.
I wonder (as someone who's basically always been in the pure software land) if the way to get around this is to overbuild your hardware prototype . Throw on more sensors, actuators, and motors than you actually need, and parameterize the physical properties of the hardware (like mass, power, and center of gravity). Then do your iterations in software. You can always ignore a signal coming from a sensor, but it takes…
It's unfortunately not that simple. For most parts you can get breakout boards or dev kits that implement the chip and all its support circuitry. You can drop those into a simple PCB or just a breadboard and get going pretty quick. This is appallingly expensive for more than a handful of prototypes, but it does work. IME, this is how software people approach electronics. The real trouble comes during the next step. Y…
To expand on this, if software was like hardware:
- when your function calls don't have enough white space between them, they'll some times mix up their return value (crosstalk)
- the more deeply your if/else statements are nested, the more random their results end up being (voltage/IR drop)
- when the user makes a selection, your bound function is called somewhere between once and a dozen times. Each time with a different value (bounce)
- their is no `true` or `false`. You just are given a float between one and zero, where one is true and zero is false. Sometimes `true` is as low as 0.3 and sometimes `false` is as high as 0.7
- the farther apart your variable declaration is from it's use, the less it represents what you actually declared. If it's two lines apart, a 'foo' string is still 'foo'. Hundred lines apart though, and 'foo' might become 5.00035 (attenuation)Re: Getting into robotics as a software engineer
#73I'm just getting into robotics with a background in software and I ended up choosing the Isaac Sim platform/ecosystem (https://docs.omniverse.nvidia.com/isaacsim/latest/index.html) and Jetbot (https://jetbot.org/master/) since they seem suited for neural networks and reinforcement learning. So far getting up and running with the simulation side hasn't been too bad and there is a model for the Jetbot in Isaac Sim since it's also by Nvidia. I haven't started on the hardware side so can't speak on that. The downside for some might be it's proprietary and Jetbot itself is a bit out of date and nearing end of life support.
Re: Getting into robotics as a software engineer
#74Earlier quoted context omitted.
It's unfortunately not that simple. For most parts you can get breakout boards or dev kits that implement the chip and all its support circuitry. You can drop those into a simple PCB or just a breadboard and get going pretty quick. This is appallingly expensive for more than a handful of prototypes, but it does work. IME, this is how software people approach electronics. The real trouble comes during the next step. Y…
To expand on this, if software was like hardware: - when your function calls don't have enough white space between them, they'll some times mix up their return value (crosstalk) - the more deeply your if/else statements are nested, the more random their results end up being (voltage/IR drop) - when the user makes a selection, your bound function is called somewhere between once and a dozen times. Each time with a dif…
If you want your program to execute as fast as possible, you have to worry about the speed of light! A trace a few millimeters longer than its partner can have nanoseconds of delay which can easily corrupt your data!
And don't forget that you have to balance the physical shape and arrangement of components and traces with frequency and surrounding components otherwise you've created a transmitter spewing out noise at tens of MHz.
Or the corollary: if you aren't careful you can receive radio signals that will corrupt your data.
Oh, you think your wire can handle the 0.5A your widget needs? Let me tell you about transients that spike to tens of amps for a few hundred nanoseconds. But it's okay, that problem can be solved with a bit of trigonometry.
On the plus side, if you forget to connect your ADC to something, you now have a surprisingly decent random number source.
I love the absolute chaotic insanity of electronics. On the surface things make sense, but one level deeper and nothing makes sense. If you go further than that, at the bottom you'll find beautiful and pure physics and everything makes sense again.
I feel the same way about software. It's a hot mess, but under everything there's this little clockwork machine that simply reads some bits, then flips some other bits based on a comparison to another set of bits. There's no magic, just pure logic. I find it a very beautiful concept.
Re: Getting into robotics as a software engineer
#75I've occasionally thought it would be fun (not necessarily productive!) to do something like the experiments folks have done with Genetic Algorithms, having simulated robots learn to walk, etc. in a simulated physics environment. The interesting bit would be to do it with real legs, sensors, servos, etc., to try to build up a "naive physics" library that can deal with balance, etc., by learning from physical experien…
You're describing something similar to what TRI has been working on for several years and seems to be making progress on: https://www.tri.global/news/toyotas-robots-are-learning-do-h...
Can anyone explain why diffusion policies are so powerful compared to just attaching a bunch of actuators to the output layer of a deep neural network?
Re: Getting into robotics as a software engineer
#76Earlier quoted context omitted.
Robotics is very niche and the market is dominated by early stage startups (since most of them go out of business a few years in), so salaries are average unless you are working specific jobs for FAANG. Job hoping usually means moving elsewhere, since working close to the hardware makes it much easier, which in turn means having a good picture of what is a competitive salary sometimes is not obvious. source: I work i…
how would you recommend a software dev break into the industry over the next 3-5 years? Preferably without going back to university. What sorts of projects are best to focus on initially?
Robotics is a broad field and is a confluence of many specialties: mechanical engineering, hardware engineering, software engineering, control, machine learning, computer vision, anything in between is a good entrance.
Coming from software, if you are interested, I would suggest either:
- Backend platform development (Python, C++ as main programming languages with a strong focus on ROS[1]).
- Frontend development (nothing too different from what's out there).
As small projects I would suggest playing with ROS to learn it and getting a running simulation with a simple robot that you can teleoperate, most of the stack already exists, it's just connecting everything together [2].
Another venue is open source contribution [1] to get known within the community and potentially attract interest from companies. ROS has multiple packages, from cloud infrastructure to drivers and simulation, if you see anything there you could contribute to, they will gladly take contributions.
In general robotics greatly benefits of good technologies from other areas, if there is a tool we use you believe could be better or a lack of good tooling in a specific area, it will get noticed.
So this would be my suggested path: learn C++/Python if you're not familiar with, learn ROS and watch which specialties appear more often in robot related jos posts [3]. If you are really invested, maybe go to a robotics conference as ROSCon to meet other enthusiasts, which companies are engaged with the community, etc.
Good luck!
Note: not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions.
[1]: https://www.ros.org/ [2]: http://wiki.ros.org/ROS/Tutorials [3]: https://discourse.ros.org/c/jobs/15
Re: Getting into robotics as a software engineer
#77This is very interesting. But quite a lot of CS people -- well at least I hope it is not just me -- end up on the web development trajectory despite or because of having less than good enough understanding of e.g. trigonometry, geometry and calculus... all of which start to matter a lot when you are starting to make things; especially things that move and consume electricity. I am a good programmer but a weak mathema…
Some trig and geometry is definitely useful—but it's quite limited to be honest. For most things you can use existing algebra libraries and for most things someone else has figured it out before!
I don’t know that I agree, even at the simple project level. If the problem you’re trying to solve has been solved exactly before and you can find a good reference to copy then you might be ok (for example the inverted pendulum problem). But in my experience you end up solving a related problem instead and that’ll often require re-deriving the equations of motion with whatever quirk is required.
The other part that’ll catch you pretty hard if you don’t have strong trig and linear algebra going for you is that debugging is going to be really hard. I admittedly have been deep in positioning-and-attitude control for 5 years now, but the ability to look at a transformation matrix or quaternion and mentally grok exactly what it means odd going to be incredibly useful when you’re trying to figure out why your system isn’t doing what you think it should be.
Re: Getting into robotics as a software engineer
#78Earlier quoted context omitted.
Mobile robotics, slam/localization and robotics backend.
Ah neat, then I do have an actual question for you. If you're using ROS 2, which version and middleware? And does it work reliably in your application? I feel like lots of companies have ditched ROS 1 only because of support being cut and cargo culting about how ROS 2 is better for unclear reasons, but in practice it feels anything but production ready to me. Everyone talks big how Zenoh will solve everything, but th…
I'm using ROS 1 Noetic on Ubuntu Focal at my current job.
I've touched ROS 2 back in 2019 during the Crystal Clemmys era but it still felt experimental back then (and I believe still was considered beta), I plan to re-evaluate later this year/early 2025 how stable ROS 2 is now.
ROS 2 is better in some aspects that weren't accounted for back when ROS 1 was developed (which started as research platform), mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from.
My personal take is that there is a lot of hit and miss between versions, no guarantee that what works now will work on the next one due to the decentralized nature of the community and the fact the team developing all this is relatively small. I would love to have a way to do small iterations on my own stack to bring it to the latest and greatest ROS release, but the combo of ROS 2 + major Ubuntu upgrade every 2 years is maybe too much for my own peace of mind.
Re: Getting into robotics as a software engineer
#79This might be a good time to get into robotics. For a long time, industrial robots were really dumb. Then there was a round of false enthusiasm for "intelligent robots" (Rethink Robotics went down that rathole.) Now, at last, compute power, vision, and AI are cheap enough that you can get something done.
The components are much better. Batteries are better. Motors are better. Radio communications work. Cameras are cheap. Short-range LIDAR is affordable. Navigation systems work. Robotics work used to require using a lot of time building custom solutions for those problems. Now you can just order components.
Here's an idea I'd like to see revisited. Back in the 1980s, someone built a pair of small forklifts that operated as a team. These were little things, about half a meter cubed, with maybe 50cm of lift. Individually, they couldn't do much. But a pair working together could pick up and move a couch, with one robot lifting each end. In the 1980s, the researchers had trouble coordinating two mobile robots. Communications alone were a big problem. Not today.
There are many material handling tasks where one small robot isn't enough, and a big machine the size of a forklift is too bulky. But teams of small robots might work.
I still have a small robot arm on my desk, but it's not connected to anything.
Re: Getting into robotics as a software engineer
#80Earlier quoted context omitted.
I'd go one further and say that basically agile in hardware is fundamentally impossible in any way people commonly use agile. If you have any custom hardware, you are basically stuck with a turn time of at minimum a day or two for any changes (often more, weeks + for new PCBs is common if you're not throwing huge amounts of money at people). In this context, any process that depends on rapid small iterations is basic…
I wonder (as someone who's basically always been in the pure software land) if the way to get around this is to overbuild your hardware prototype . Throw on more sensors, actuators, and motors than you actually need, and parameterize the physical properties of the hardware (like mass, power, and center of gravity). Then do your iterations in software. You can always ignore a signal coming from a sensor, but it takes…
It's common to design PC boards that have holes and traces for components that aren't installed. If you need three motor controllers now, design a board with space for six, plus a prototyping area of plain holes. Allow for extra sensors, inputs, and outputs. It's easy to take the extras out of the design later when you make the board for the production product.