NASA have plans to use rotorcraft in many future missions, including the Dragonfly which will fly around Titan[0]. Launches in 2027.
[0] https://www.nasa.gov/press-release/nasas-dragonfly-will-fly-...
NASA have plans to use rotorcraft in many future missions, including the Dragonfly which will fly around Titan[0]. Launches in 2027.
[0] https://www.nasa.gov/press-release/nasas-dragonfly-will-fly-...
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...
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...
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.
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.
[1] https://mars.nasa.gov/news/8926/nasas-perseverance-mars-rove...
Ingenuity isn't a quadcopter though, it has two blades that counter-rotate around the same axis.
Which would make it a coaxial helicopter.
Surely a better test would be to get 1000 mobile phone processors and put them in a radiation chamber on earth and see how many fail? It would be far cheaper and be better science.
If we want to see and explore deep valleys or high mountains before some future the first setlers go there with gopros and do a Twich stream then flying drones are a good option.
Hopes/Scheduled to launch in 2027 seems more accurate. Even when the rocket is fueled and on the pad, it can still get scrubbed.