Comment by NovemberWhiskey | Hacker News Reader

Comment by NovemberWhiskey | Hacker News Reader

Parent Full thread

NovemberWhiskey

>Rotorcraft require more computing power than is available from typical rad-hardened processors.

Ingenuity uses a three-level control system for avionics[0] - the Linux part that runs on the Snapdragon 801 is at the top tier and does more the mission computer functions like navigation, computer-vision, telemetry, command processing and interfacing to the radio.

The middle tier is a dual-path redundant microcontroller system based on the TMS570 architecture. This is an automotive-grade part qualified for safety-critical usage. This an ARM Cortex R5 design, so not exactly a speed demon.

The bottom tier is a radiation tolerant, mil-spec FPGA (Microsemi ProASIC 3L) that actually runs the control loops at up to 500Hz, handles communication with the IMU, motor control interfaces etc; this part is actually supposed to be functionally identical to the space-qualified version.

The "Linux running on a smartphone processor" aspect gets a lot of play but the stack as a whole uses a lot more traditional high-integrity design approaches. Most of the heavy-lifting of "fly the rotorcraft" is done away from the Snapdragon, and I'm not sure where the idea that "rotorcraft need a lot of CPU power" comes from.

[0] https://rotorcraft.arc.nasa.gov/Publications/files/Balaram_A...

>Rotorcraft require more computing power than is available from typical rad-hardened processors.

the CPU on a fairly advanced quad, hex or octocopter on earth can be a STM32F7 or STM32H7 family microcontroller, which is not very powerful in terms of raw computing power. That's more than fast enough (in an earth environment) to pull in sensor input at a high Hz refresh rate from dual IMUs, barometer, GPS, and control up to eight motor ESCs, along with running the UARTs for communication to a remote control link, and additional spi, i2c or UARTs to do things like run camera gimbals.

https://docs.px4.io/master/en/flight_controller/cubepilot_cu...

Yeah, I think the biggest factor preventing such a simple design from working well on Mars would be the (current) lack of anything equivalent to GPS.

In order to navigate safely, especially during takeoff and landing, you need a reasonable idea of your absolute velocity relative to the ground. You can't get that from an IMU (except over very short timescales) because of integration errors. A barometer would work for the vertical axis, but getting the horizontal component is a lot trickier. GPS solves this nicely, especially since velocity can be derived from relative measurements, which are much more accurate than absolute ones.

It looks like Ingenuity uses visual odometry from a downward-facing camera, which is likely to require a lot more processing than something like an STM32 could provide.

>It looks like Ingenuity uses visual odometry from a downward-facing camera, which is likely to require a lot more processing than something like an STM32 could provide.

I believe that for Ingenuity they are actually doing this in software; but at this point, you can just buy off-the-shelf an optical flow odometry ASIC with a built-in camera and lens system that draws <5mA, fits in a 4x5mm footprint and gives you delta-X and delta-Y.

e.g. https://www.pixart.com/products-detail/108/PAA3905E1-Q

Kinda mind-blowing.

Is that kind of like optical mouse sensor?

Yes it is! Obviously it's a slightly harder problem if you don't know the distance from the surface and you can't provide your own illumination.

That's one of those missions I'm actually really hoping I live to see: a whole sequence of launches putting a GPS constellation into orbit around Mars.

At the relatively low heights ingenuity is flying at, a single point LIDAR rangefinder aimed straight down would also be well suited to maintaining a certain altitude.

Reply on news.ycombinator.com