Live data from Hacker News

Getting into robotics as a software engineer

bou.ke

61–70 of 105 posts

Re: Getting into robotics as a software engineer

#61
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…

https://m.youtube.com/watch?v=17NrtKHdPDw

I had seen that. The assumption seems to be that simulations are simplistic, and then most of what remains shows practical ways for real world training to work (while acknowledging that it's hard to do)

Re: Getting into robotics as a software engineer

#62

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…

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 weeks to add a new sensor and get a new prototype. So work out all the behavior in software, where you can iterate on a minutes -> hours timetable.

Then once you know how it works and have done most of your optimizations, you can trim down the BOM and get rid of hardware that proved useless. You'd probably want another round of tuning at this point, but at least you know basically how it works, and have tried out many different combinations of hardware in your software iterations.

Re: Getting into robotics as a software engineer

#63

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

That's what dev kits are in electronics. They usually even come with schematics/PCB layouts so an engineer can quickly copy a working design and remove the stuff they don't need. There's still a huge gulf between those prototypes and production and there's plenty of mistakes to make requiring multiple revisions.

Re: Getting into robotics as a software engineer

#64
post #42

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.

What is questionable-value? People pay for questionable things, that brings value to them, though that value is questionable? Do not get it. Though i understand the personal resentment.

Value to society, which is different than value to companies or individuals.

Re: Getting into robotics as a software engineer

#65

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

That's what dev kits are in electronics. They usually even come with schematics/PCB layouts so an engineer can quickly copy a working design and remove the stuff they don't need. There's still a huge gulf between those prototypes and production and there's plenty of mistakes to make requiring multiple revisions.

It was the same end-position prior to internet publishing of software.

No updates. No bugfixes. What you pressed to CD (as much as a buck per CD qty 1000), was what your customers got. Period.

And it hurt to republish, because those updates were via mail. The box/sleeve, the labelling, the labour, the shipping.

DEVs today have no idea how easy their push is.

Get it right or you fail.

Re: Getting into robotics as a software engineer

#66

Earlier 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 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. You have to integrate all these disparate boards into one unit. You can copy schematics and layouts from the dev boards, but that takes a lot of time. Once you've done that, you need to re-validate your entire stack, electronics, firmware, and software. You will inevitably find that you've missed a connection or the routing introduced some noise or you got this component value wrong. So you spin a new board, wait a week, and do it all over again several more times.

Debugging electronics is a lot like debugging software. Except that the code is physical objects and the bugs are emergent properties of the whole system and are inherently chaotic. You (generally) can't step through the system like you would with code, you can only observe a small number of nodes in the system at any one time.

It's harder than you expect because you're dealing with invisible forces and effects of the fundamental laws of physics. It requires either very deep knowledge or a lot of time in iterations to solve some of these problems.

Re: Getting into robotics as a software engineer

#67
The article itself was a bit too holier-than-thou for me but I want more robotics content here on HN so let's hijack this thread and share robotics passion!!

My own shitty first foray into robotics is an RPi that I can talk to [2].

If you didn't see "the coolest robot I've ever built" you gotta watch that... so inspiring [3]

Latent Space has a robotics demo day coming up, pretty curious to see what comes out of that [4]

Some stream-of-conscious thoughts about why I'm drawn to robotics:

* The maker / hacker / homebrew communities that are basically just using robots to express art. Maker Faire, Burning Man, etc.

* The satisfaction of writing code and seeing something physical happen. Last week I was trying to figure out how to get a shitty third party Amazon robot hat [5] to actually do something useful so I was iterating through the GPIOs and I somehow made it actually smoke. I'm weirdly proud of messing up so badly that my hardware actually smoked!

* The joy of demystifying hardware and learning all the layers of abstraction just within hardware

[2] https://www.biodigitaljazz.net/blog/STTTGTS.html

[3] https://news.ycombinator.com/item?id=38162881

[4] https://lu.ma/latent-space-final-frontiers

[5] A Xmas present from my sweet wife, really touching that she's encouraging me to actually pursue my interest in robotics

Re: Getting into robotics as a software engineer

#68

What would be a good starting platform for a programmable drone? The article suggests playing around with a Raspberry Pi Pico, but this is a bit bare bones. Are there any kits, or entry level programmable drones on the market with a reasonable toolchain to program sequences?

This one seems to have completely open source hardware / firmware / software:

https://www.bitcraze.io/products/crazyflie-2-1/

https://www.bitcraze.io/documentation/repository/

It was mentioned in this IEEE Spectrum article: https://spectrum.ieee.org/drone-quadrotor-2667196800

Re: Getting into robotics as a software engineer

#69
post #4

This is completely unrelated to the article the OP posted other than it's also related to robotics. But it's the coolest robot project I found recently. And since readers of this thread are likely to be interested in robotics (I am!), it might of interest to some: https://www.allesblinkt.com/projects/round-about-four-dimens... Hope this is not considered too off-topic here.

The original post is kinda lame so we should just hijack this thread into a general robotics appreciation discussion.

That cube is amazing. Thanks for sharing. The aesthetic is so polished. Some true 21st century art right there.

This made the rounds a few months ago but worth posting here again. So inspiring. https://www.youtube.com/watch?v=bO-DWWFolPw

Re: Getting into robotics as a software engineer

#70

What would be a good starting platform for a programmable drone? The article suggests playing around with a Raspberry Pi Pico, but this is a bit bare bones. Are there any kits, or entry level programmable drones on the market with a reasonable toolchain to program sequences?

Have a look at the Crazyflie https://www.bitcraze.io/
Post reply on HN