A Look At The “Risky” Tech In NASA’s Martian Helicopter

On February 18th, the Perseverance rover safely touched down on the Martian surface. In the coming days and weeks, the wide array of instruments and scientific payloads tucked aboard the robotic explorer will spring to life; allowing us to learn more about the Red Planet. With a little luck, it may even bring us closer to determining if Mars once harbored life as we know it.

Among all of the pieces of equipment aboard the rover, one of the most intriguing must certainly be Ingenuity. This small helicopter will become the first true aircraft to take off and fly on another planet, and in a recent interview with IEEE Spectrum, operations lead [Tim Canham] shared some fascinating details about the vehicle and some of the unorthodox decisions that went into its design.

Ingenuity’s downward facing sensors.

[Tim] explains that, as a technology demonstrator, the team was allowed to take far more risks in developing Ingenuity than they would have been able to otherwise. Rather than sticking with legacy hardware and software, they were free to explore newer and less proven technology.

That included off-the-shelf consumer components, such as a laser altimeter purchased from SparkFun. It also means that the computational power packed into Ingenuity far exceeds that of Perseverance itself, though how well the helicopter’s smartphone-class Snapdragon 801 processor will handle the harsh Martian environment is yet to be seen.

On the software side, we also learn that Ingenuity is making extensive use of open source code. Not only is the onboard computer running Linux, but the vehicle is being controlled by an Apache 2.0 licensed framework developed by NASA’s Jet Propulsion Laboratory for CubeSats and other small spacecraft. The project is available on GitHub for anyone who wants it, and according to the changelog, the fixes and improvements required for the “Mars Helicopter Project” were merged in a few releases ago.

The fact that code currently ticking away on the surface of Mars can be downloaded and implemented into your own DIY project is a revelation that’s not lost on [Tim]. “It’s kind of an open-source victory because we’re flying an open-source operating system and an open-source flight software framework and flying commercial parts that you can buy off the shelf if you wanted to do this yourself someday.”

Of course, it took a whole lot more than some Python libraries and a handful of sensors from SparkFun to design and build the first space-going helicopter. But the fact that even a small slice of the technology inside of a project like Ingenuity is now available to the average hacker and maker is a huge step towards democratizing scientific research here on Earth.

[Thanks to Måns for the tip.]

35 thoughts on “A Look At The “Risky” Tech In NASA’s Martian Helicopter

  1. “But the fact that even a small slice of the technology inside of a project like Ingenuity is now available to the average hacker and maker is a huge step towards democratizing scientific research here on Earth.”

    Citizen science with a smartphone full of sensors all made cheaply enough anyone can buy it, linked via a communications network that spans a large part of the planet…yes, I’m talking Skylink. :-)

  2. It’s really cool that consumer-class COTS hardware stands a chance of working in the fairly harsh environment of Mars, with apparently not much more than insulation and a heater for the avionics. That Garmin LIDAR looks fairly exposed, however.

    I hope we see a lot more lower cost higher risk probes/rovers in the future. Perhaps with the lowering cost of space access.

    1. To be fair, we don’t yet know if that COTS hardware is going to survive long enough to actually perform a test hover (let alone flight). It’s still going to be a month or so before the rover even drops the bird, and after that, my understanding is that its going to have to sit on the ground and be self sufficient for at least a day or so before they spin up the rotors.

      Night on Mars is no joke, especially when you don’t have the luxury of a nuclear backpack to keep you warm.

  3. I looked at the code they are making available. Trying it out on a Pi is almost as difficult as making a whirly bird fly on Mars. And I can see making it work on a whirly bird drone down here almost as easily as up there.

    1. They have tested it at reduced pressure, seem some trial info somewhere.. But still tuning it on Earth with 1G is going to be tricky even if you get the atmospheric pressure right can’t easily mimic the lower gravity of Mars – it has got to be some educated guesses..

    2. There’s video of them doing tethered flights in the vacuum chamber. That was one of the first questions they needed to answer before they rocketed it off to Mars: can the propellers actually generate enough thrust in the wispy atmosphere to lift the thing.

    3. Why would you think they use PID? And why the hell would you thing they would tune it even if they had decided to use them instead of just veryfing the model and the ouright setting the global best parameters for specific bounded weather conditions?

      PID tuning is for nonengineers and lazy industry people.

      1. Seems for most rc drones the pid does pretty well. The more advanced control systems don’t give much extra performance, unless you have very good sensors (eg camera tracking instead of IMU/GPS)

      2. Wrong side of the bed this morning darling? Basic grammar kick you out before breakfast? Love me a bit of PID. Comes in super handy when you don’t have the full picture and need something to just behave rather than spend hours purity mining. Lazy? Subjective. Does the job? Totally.

  4. Law of EE #1: Never design in parts from Sparkfun. I worked with an EE that broke this unwritten rule. He designed in a loadcell ADC from Sparkfun. The part was a knockoff of an Analog Devices part, except it had a horrible communication interface that either required you to bitbang it, or to bastardize your SPI driver to get it to work.

    Also, the part was only available in China and had a six month leadtime.

    Seriously. Don’t design in parts from Sparkfun. Their supply chain has advantages you do not. Even if you can source the actual parts, you’re getting the shittiest of bottom-tier knock-off parts. This kind of stuff is great for hobby work, especially when it’s cheap and has working arduino drivers, but when it comes to professional applications, it’s hobby trash.

    1. +1 this. When designing for the non-hobby world, for example real products, one refers constantly to reference data sheets, uses well known and established supply chains and builds in testability. That way, when things inevitably go sideways, you have the resources of the manufactures and supply chain to assist with troubleshooting.

      1. Back when I was doing engineering, a few of my projects, or more specifically, some I contributed to, were deployed to ocean surfaces and depths under contract to NOAA and others (underwater communication for divers and buoy sensors).

  5. As a US taxpayer, I hope they succeed with the consumer grade components, but a part of me is sad they did that. Going cheap on a mission to Mars seems like a huge waste. I fear they put the greenhorns on that part of the project. Time will tell.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.