Hacker News Reader

Comment by pclmulqdq | Hacker News Reader

As someone with an EE background, it surprised me that something with such a meticulous mechanical design had a comparatively amateurish set of electronics that seemed to be cobbled together out of a mix of hobbyist parts.

At day 0, they could likely have found an SBC with native CAN and RS-485 (or just used a UART to 485 converter), and enough USB ports for the sensors, which would have simplified the design a lot. A different battery controller or a few capacitors likely could have managed the "power surges" as well.

View on HN

A lot of robotics projects like this are done by people who only have a background in mechanical engineering. This team seems to have dedicated software people so they can use ROS (Python/C++). However it's common in robotics to just draw something in Simulink/Stateflow that is pushed to the microcontroller or FPGA. No low-level C expert required.

I'm sure most software people will be horrified how much "safety critical software" in modern cars and aircrafs is autogenerated based on something drawn up in Simulink/Stateflow.

Is this really that bad? Presumably the autogenerated c doesn't have any array over reads and it probably initializes values properly

I think companies that do actual life/death safety critical software should hire dedicated software people instead of relying on closed-source proprietary visual programming tools for mechanical engineers.

Simulink / Stateflow and more generally 'synchronous programming languages' have a rich academic lineage and are particularly well adapted to safety-critical tasks.

These languages bring a lot of key guarantees that you can't (easily) get from more classical languages like bounded memory usage, hard real time guarantees, numerical properties, ability to prove theoretical properties about the model etc...

It's also not like having your code written as a text file would save you from using closed source proprietary compilers or languages (Ada, Ferrocene, various C distributions) for safety-critical software.

Rather than "instead" it can be both. I don't want mechanical engineers hand writing observer models and PIDs in bare metal C, but I also don't want software engineerings designing my observer models and PIDs. They are different tools for different jobs.

Those tools are closed source so they probably have many undiscovered bugs.

What’s wrong with Simulink? It is better than the average C developers code in terms of safety and correctness

Yes, in addition to Simulink, see AUTOSAR:

https://en.wikipedia.org/wiki/AUTOSAR

From my understanding it's very prevalent in automotive to generate microcontroller code.

While AUTOSAR does generate code, the code is highly coupled with the "core" of the module, it's more configuration data rather than the logic itself.

There are 3 large fields IMHO to make a robot like this: hardware, electronics and software. Same for a large range of hobby-robotics like rc planes, legged dogs, etc. It's VERY difficult to be an expert in all of those, like being an expert in only one of those is already a lifetime career if you want, let alone two or even three. Oh and also, in any of them to make a robot like this would also be specialized, e.g. in software you'd need to know quite a lot about inverse kinematics, rigid body mechanics, PIDs, etc.

But the nice thing of 6-legged robots and such, is that to make them at the "hobby" level you don't even need to be an expert in those fields; knowing one well and then the basics of the other two is enough to follow tutorials and build it! And it's also a lot of fun and I'd recommend anyone with a small interest to try it. I created one of those with a couple of friends, in a much rougher way (but it worked!) in a couple of days.

I can confirm that at the mechanical hardware level you'd also typically have specializations. At the very least I'd see one design engineer (CAD, designing parts for manufacturability, selecting COTS systems based on requirements) and a controls engineer (simulating and analyzing kinematics and dynamics of moving parts and setting up the controls algorithms to be used).

One jack-of-all trades engineer could for sure do both, but in larger projects with high budget (BD, NASA rovers, etc), you'd have even more different specializations just in mechanical engineering: thermals, structural analysts, motorization experts, etc.

I'm very interested in such a project. Is there some online lectures, books or other resources wher you could learn to build a robot like this on a good level (both mechanical and electronics)?

Just curious if it can be learned online or you rather need to join a company to get the basics.

PS: I'm asking because for example in Software that was a really amazing exprience, to learn in a team. Although I had a good background. Don't think the knowledge can be learned from books or from some tutorials.

James Bruton's videos might be a good place to start.

https://www.youtube.com/user/jamesbruton

As someone who works in embedded software, you see this a lot.

Of course, if you've seen hardware products designed by mostly software teams, same sorta issues, but on the hardware side.

I've interviewed at quite a few startups where the hardware was a raspberry pi/jetson strapped to some 80/20. Whether they fix the mechanical design or EE side first usually depends on whether they need to ship and go "shit this 80/20 is expensive" or hit power issues/USB enumeration nightmares on important sensors.

A step further, I probably would have used something not running a GPOS for the main computer. Depending on the details, probably used an STM32H7 etc, and either run most of the logic on it, or delegated to other MCUs as-required for specific tasks like servo control.

A lot of embedded processors and SBCs other than the RPi have both a general-purpose computing environment and a real-time environment. Usually, the general-purpose environment is the main system, and it boots up the real-time system when required. I don't think any of them are nearly as convenient as using Python on Linux, though.

It's hard to fault them for reaching for a powerful core when they have the kitchen sink worth of high-bandwidth sensors on the thing, including 4 cameras and a LIDAR.

It’s much faster to develop, test, and iterate on a real OS, with a file system to write logs to and network to push code over.

Reply on news.ycombinator.com