Live data from Hacker News

Getting into robotics as a software engineer

bou.ke

81–90 of 105 posts

Re: Getting into robotics as a software engineer

#81

Nice article. As someone who's also gotten into robotics from the software side, I'd also suggest learning a bit about the hardware side. If you're doing anything with custom boards and board bring-up, you'll need to be able to read a schematic and data sheet at a basic level. Being able to use an oscilloscope and logic analyzer is also _very_ useful. None of this stuff is terribly hard, but it's nice to know what to…

Yes.

The number of people who both know C++ (not C) and how to use an oscilloscope is surprisingly small.

Electronics at robotic speeds isn't that hard. Most signals are audio bandwidth or lower. You rarely need all the elaborate design techniques needed when you get into the MHz-Ghz range.

Re: Getting into robotics as a software engineer

#82
post #73

I'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…

You'll be better served with a more capable platform. You can either 3d print it, or you can pick up something like the WaveRover from Waveshare. It's a solid metal frame with geared motors and differential drive. For ~$100 you won't get much better.

You just need to pop in 3x18650 batteries in the chassis and connect a Jetson nano to the UART pins. It has an ESP32 inside, so you can also program that, but it comes programmed out of the box.

You can control it with this python library https://github.com/msanterre/wave_rover_serial

Isaac SIM is a terrific simulator, you won't get much better.

Re: Getting into robotics as a software engineer

#83

Earlier quoted context omitted.

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 (no…

> not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions.

In academia, yes. ROS is a piece of middleware for passing messages around, and a standard for talking to it. Funding agencies pushed academic robotics projects to talk to ROS so that results from different projects could interoperate. Which they sort of do. You get a lot of tooling for logging, user interfaces, wiring things up, etc. Think of it as a solderless breadboard for robotics software. The final product probably doesn't use it.

Re: Getting into robotics as a software engineer

#84
post #82
post #73

I'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…

You'll be better served with a more capable platform. You can either 3d print it, or you can pick up something like the WaveRover from Waveshare. It's a solid metal frame with geared motors and differential drive. For ~$100 you won't get much better. You just need to pop in 3x18650 batteries in the chassis and connect a Jetson nano to the UART pins. It has an ESP32 inside, so you can also program that, but it comes p…

Cool, thanks for the advice!

Re: Getting into robotics as a software engineer

#85

My journey is a little bit opposite to the author’s: I studied robotics and started learning programming by myself to create software for robots. There are two observations I have that can be useful to people making the software->robotics journey. * Agile for software-hardware is hard if not impossible. For software it can be reasonable, but it’s really hard to iterate on both hardware and software at the same time.…

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…

When hardware design can be software emulated then iteration can be more agile. There's a story how NVIDIA was the first one to do this for GPUs- this was done out of desperation because they were out of money and had to ship quickly. They didn't have time and money to do any revisions so they just shipped what they had done in software emulation even though some of the features were defective. https://www.acquired.fm/episodes/nvidia-the-gpu-company-1993...

Re: Getting into robotics as a software engineer

#86
post #3

I'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…

System Identification is a fairly common strategy for developing a controller. Essentially, you learn the dynamics model from recorded data, and then use that as a simulator to iteratively improve the controller. The devil is in the details though, as you can run into issues with simulation fidelity (due to missing data), which can produce something that doesn't translate to real life performance.

Re: Getting into robotics as a software engineer

#87

Earlier quoted context omitted.

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 distrib…

That makes sense, Noetic is rock solid compared to any ROS 2 release so far imo. I hope that this year's LTS will be more reliable (again with the whole promise of Zenoh rmw) but I remain sceptical since all the major fixes always get backported and Humble is not exactly a beacon of stability.

> mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from

Yeah that was the theory anyway, I'm not sure how much of that had really worked out as intended. Automatic discovery without a roscore has proven... unfeasible. Especially over wifi since the required amount of multicasts basically runs a continuous ddos attack and now we're moving back to the same old concept with FastDDS Discovery Server, Zenohd, and the ros2 daemon. Sure the DDS technically has encryption now, but I've yet to hear of anybody using it. Overall it's just a mess.

When you're doing that evaluation, take a good look at python nodes and their performance compared to Noetic. Currently it's bad, like horrendously bad, 30x less efficient in some cases that I've tested. And they've also ported the CLI parts from bash to python so tab autocomplete and parameter fetching take like actual seconds. I just don't know...

Maybe there's lots of systems out there already running on Cyclone or FastRTPS that make it all worthwhile, but I haven't really heard of any such cases.

> the combo of ROS 2 + major Ubuntu upgrade every 2 years is maybe too much for my own peace of mind

Yeah 2 years seems a long time, but it never turns out that way. It really pains me to see useful packages made obsolete and unusable again and again for no reason but moving to the next release which usually brings effectively nothing by itself.

Re: Getting into robotics as a software engineer

#88

Really wish the author would have commented on salary. I personally think the reason more people don't end up on the hardware/robotics side is that the questionable-value fintech/adtech/socialtech pure software side of the world pays so much better and most developers follow the money.

Definitely agree here. I have been making this transition and currently work on life science lab automation robotics. It definitely takes intentionality because if you're good at software it's easy to get steered towards lucrative but higher level places in the stack.

Re: Getting into robotics as a software engineer

#89
post #83

Earlier quoted context omitted.

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 (no…

> not everything robot related is done in ROS, but it's almost a standard within the field save for a few exceptions. In academia, yes. ROS is a piece of middleware for passing messages around, and a standard for talking to it. Funding agencies pushed academic robotics projects to talk to ROS so that results from different projects could interoperate. Which they sort of do. You get a lot of tooling for logging, user…

> The final product probably doesn't use it.

I disagree here, usually projects that are not keen on relying on ROS end up re-implementing a lot of the groundwork (shared memory, message distribution, parameter server, logging, etc.), usually they are older products (10 or 15+ years old), where ROS wasn't really a thing and migrating to ROS after implementing their own tailored stack is not worth it.

Re: Getting into robotics as a software engineer

#90

Earlier quoted context omitted.

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 distrib…

That makes sense, Noetic is rock solid compared to any ROS 2 release so far imo. I hope that this year's LTS will be more reliable (again with the whole promise of Zenoh rmw) but I remain sceptical since all the major fixes always get backported and Humble is not exactly a beacon of stability. > mainly distributed systems (multi-robot environments) and good tech developed elsewhere that the system could benefit from…

> Currently it's bad, like horrendously bad, 30x less efficient in some cases that I've tested.

Ouch. Back when I played with it efficiency wasn't even under discussion, as the basics had just gotten there (topic/service/action support), last I paid attention to this matter was during to some performance/inconsistencies of FastDDS (during Foxy, maybe?) from which the default was changed to Cyclone, but I must admit I'm a bit out of the loop.

> Yeah 2 years seems a long time, but it never turns out that way. It really pains me to see useful packages made obsolete and unusable again and again for no reason but moving to the next release which usually brings effectively nothing by itself.

Yup. Two years makes sense for cloud, but with hardware involved and a fleet deployed in varying conditions around the world, 2 years to migrate a major version of ROS and Ubuntu is maybe too short (not even considering packages that you depend on that might not be ported at all). I would love to see other distros with longer spans (Alma/RHEL/Debian) becoming 1st class citizens and ROS releases turning into incremental versions running on the same platform until they reach EOL, at "robotics pace" that would be fantastic.

Post reply on HN