Ingenuity

Last Monday, NASA have flown their helicopter for the first time on Mars, and it was lauded as big success. Which it was, from an engineer’s perspective. I don’t care about all the talk like “more than 100 years after the Wright brothers on Earth, humankind is now flying on another planet” and yadda yadda. I care about the engineering challenges, though.

So let’s nerd out a bit.

We have all these quadcopter (four propellers) or hexacopter (six propellers) drones, and they fly reliably, are easy to pilot, and are relatively cheap, so what’s the big deal? If you have followed all this at least from the sidelines, you must have heard that the atmosphere on Mars is only about 1% as dense as on earth, so rotating blades only produce a fraction of the uplift, and that this can be compensated by rotating faster. Gravity is only about a third up there, compared to Earth, so that helps. But why not using a quadcopter or hexacopter on Mars in the first place, building upon and improving the relatively simple and proven technology of commercial drones?

Some Background

About ten years ago, I had built my own hexacopter. For aerial photography. Or so I had told myself. More than half of the fun was actually building, modifying, and upgrading it. Today, DJI is known for their ready-to-fly drones of all sorts, but back then they just offered components to build them. That’s how they started. Frames, motors, and most importantly the electronics to control the drones. You then added a standard model-plane radio remote controller, Graupner model-plane propellers, landing-gear, and so on. Luckily, no mechanical servos are necessary, as such a drone is flown purely by controlling the electrical motors. With all the components, it was relatively easy to build the thing. And also easy to repair whenever I damaged it during flight. Replacing one of the arms with the motor and propeller on it, broken due to, say, overly optimistic piloting? Easy and cheap. Good luck with that with today’s ready-made drones.

Starting from the basics, just happily being able to even lift off and fly around, I then improved and extended the design with a fixed camera first, then one on a gimbal. And later a video downlink so I could “see through” the GoPro camera during flight, with goggles that had a small LCD screen in front of one eye, while the other could still see the the drone from afar. And so on. I also had experimented with different motors, rotor sizes, and batteries for different uplifts and flight characteristics.

It’s just incredible what kind of manoeuvres you can fly with a drone. A plane can only reduce speed, while a drone can break mid-air, until it starts to fly backwards, and while breaking making a right-left turn, and go full speed ahead again, for example to avoid an obstacle. And I am a bad pilot. Check out some videos on YouTube to see what real drone pilots can do. Crazy.

Anyway, lots of fun with both mucking around with the apparatus as well as piloting. And I had learned a thing or two.

Quadcopter on Mars? Nope.

We know that the Ingenuity helicopter has to spin its rotors at about 2,500 RPM. Which is way faster than would be necessary on Earth, where some 300 RPM would suffice. Flying on Mars is like flying at about 30,000 metres of altitude in Earth’s atmosphere. No earthly helicopter can fly that high. In fact, no chopper can even fly up to the top of Mount Everest, ie. just under 9,000 metres. The blades just don’t produce the required uplift anymore, even at their maximum RPM. Which is probably a Good Thing,™ else we would have helicopter tourists even up there.

Now let’s say the Mars heli’s rotors spins eight times as fast as would be needed on Earth. The blades of a quadcopter down here spin at some 15,000 to 30,000 RPM, or even more, depending on the size, weight, propeller size and shape, and so on. That’s why they produce such an annoying sound. Extrapolating, a quadcopter on Mars would need to spin its blades at 120,000 to 240,000 RPM. Good luck finding, or even constructing an electrical motor producing and most importantly reliably withstanding that.

So a quadcopter design appears to be a non-starter for Mars, and NASA’s decision for a heli not surprising. 2,500 RPM are easily with the realm of the technologically possible, even if a huge challenge given the limited available energy in a tiny and sufficiently light battery, not least considering that the rotors are 1.2 metres in diameter, which requires quite some torque and power. The wide blades, and their very distinct shape, are required for the uplift, too, but need even more torque.

Controlling the Flight

Even though a quadcopter would have advantages. There are no moving mechanical parts needed to control the flight of a quadcopter or hexacopter. The movements and the attitude – yaw, pitch, and roll – are completely controlled by individually changing the rotational speed of single motors. Pure electronics. DJI still sells these components. Strictly for earthly use. When I checked this out the other day, I remembered, Ah, yes, the Naza! Memories.

A heli, on earth or on Mars, on the other hand, requires to mechanically swivel the blades along its longitudinal axis. Otherwise, it can only go up and down by changing the rotors’ RPM. To create a force forwards, backwards, or sideways, the blades need to swivel back and forth to defined degrees – continuously changing back and forth on every rotation. It’s basic helicopter design and technology, as is the need for two rotors rotating in opposite directions.

And indeed, if we check out the pictures of Ingenuity, we in fact recognise the mechanics for exactly that, below both rotors. I suspect they have contributed quite some weight to the total 1.8 kg. They appear to be constructed of metal, which wouldn’t be surprising, given their task of swivelling the blades during each rotation, and the corresponding forces they must withstand at the high RPM. Maybe it’s some metallic-looking compound? I haven’t found any information on this specific detail.

Also, the chopper is folded up during the journey to Mars, and everything has to unfold into position, and lock firmly there, which adds to the complexity and reliability requirements of all mechanical components. No unfolding, no locking, no flight. No-one around to lend a hand in case, say, the locking mechanism jams, for example due to dust, or the freezing cold on Mars. I am not a mechanical engineer, which probably makes me admire these guys and gals unduly. Software and electronics seem easy in comparison. Software can even be updated remotely. A jammed locking mechanism is the end of the mission.

Energy and Power

Commercial drones down here have flight times of 20 to 30 minutes, give or take, until the battery is drained. Yes, it’s a good idea to land the drone before that happens. Today’s drones have built-in battery monitoring, and will land the drone autonomously, or even return to the starting point automatically before landing. The latter is a good idea, as the lift-off point is also a good landing point, while simply landing anywhere could be hazardous. You can even catch them by hand when they return, but unless they have a cage around the blades, I would not necessarily recommend this. Those blades have sharp edges, as they should have for reducing drag. I still have some scars, even though not of trying to catch the drone mid-air. I sanded the edges, and also sanded off parts of the material on one side to make sure they were well-balanced. Otherwise the high-RPM rotation can cause vibrations, which was not good for the picture quality, and it puts strain on the motors and the frame.

Anyway, I was curious about the flight times on Mars. The aforementioned Wikipedia article says that the flight time of the Mars chopper is “Up to 90 seconds per flight.” 20 minutes vs. 90 seconds. I would assume that the 90 seconds are partially a limitation driven by concerns for flight and mission safety and security, with ample margins to what would be technically possible. Still.

For a given weight and gravity, the battery is clearly the limiting factor, down here and on Mars. Let’s look at some data.

The Wikipedia site says Ingenuity’s Lithium-Ion battery weighs about 280 grams. It has an energy capacity of 40 Wh (Watt-hours), or 2 Ah (Ampère-hours), which means the battery produces about 40 / 2 = 20 Volts.

A typical Lithium-Polymer battery I had used for my hexa weighs about the same, produces around 12 Volts, between 35 and 70 Amps of current, and has a capacity of 3400 mAh, ie. 3.4 * 12 = 41 Wh. Alas, I cannot remember the total weight of my drone. Maybe just over 1 kg? As an aside, check out these figures for the current, 70 Amps out of a puny battery! The flight motors can draw lots of energy. The Mars heli’s battery’s higher voltage has the obvious advantage that the currents are lower at the same power draw, which is good for the construction as electrical conductors with lower diameter suffice.

Today’s commercial drones also use higher battery voltages in that range, and some make use of Lithium-Ion batteries as well. Probably a good idea for a drone on a remote planet: if not being charged properly, or if shorted, Lithium-Polymer batteries can catch a sort of fire which is very hard to extinguish. We had special fire-proof pouches to charge, store, and transport the Lithium-Polymer batteries.

Let’s use the following data point. DJI’s Inspire¹ drone weighs about 2.8 kg, with battery, camera, and camera gimbal. It has a Lithium-Polymer battery of 100 Wh, 22.2 Volts, which weighs just under 600 grams. The Inspire has a flight time of 15 to 20 minutes.

Now some simplistic and possibly inaccurate estimations. Hypothetically, let’s say the DJI Inspire also has a 40 Wh battery, and the flight time is proportional to this capacity. Then it would fly for six minutes (15 mins * (40/100)). Now let’s correct for weight, as Ingenuity is lighter than the Inspire, again assuming proportionality, and we go up to over 9 minutes (6 mins * (2.8/1.8)). If we account for gravity in the same way, the flight time goes up to 28 minutes (9.3 mins * 3).

Inaccurate as the above rough estimation is, 90 seconds and 28 minutes are really far apart. As said before, I cannot know what safety margins NASA use for the 90 seconds flight time spec. But, bottom line, I think this shows how energy-demanding flying in the Mars environment is. Spinning these huge blades simply requires lots of power. Compared to the motors, every other energy consumer aboard the heli is probably more or less negligible.

Development and Testing

In an engineering mind, the question about testing down on Earth during the design and development of this kind of machine inevitably pops up. I don’t know how difficult it was to construct and operate the vacuum chamber to create the 1% air density, sufficiently big to actually test the flying behaviour. Then, how do you simulate the one-third gravity? From what I read the developer team used a cable from the top, pulling up with two thirds of the heli’s weight. Which of course impacts the flying characteristics. Not ideal, but not a bad trick either. This just shows how difficult testing was, never actually replicating the actual conditions on Mars. No wonder the dev team awaited the data of the first flight under great strain and tension.

Which reminded my of the Lunar Landing Research Vehicle in the Apollo era, and its successor, the Lunar Landing Training Vehicle. It had a rocket engine, mounted on a gimbal, dedicated to simply blasting vertically down to cancel out 5/6 of the vehicle’s weight, in addition to the actual engines for piloting. That is, the vehicle behaved as if on the Moon with respect to gravity.

Before I read about the cable trick for the Ingenuity testing, I had considered the possibility that they might have used a similar technique, but this probably would have added too much weight to the heli under test, substantially changing the flight behaviour.

Autonomy

Radio signals between Earth and Mars take between four and 24 minutes, depending on the relative position of the two planets during the year. Obviously, any kind of direct control is impossible, the helicopter has to fly completely autonomously. The ground crew programs the flight path upfront, sending that data up before the mission, and the vehicle will then execute on its own.² Big deal, you might think, don’t we have this also down here, as there are commercial drones that can be programmed to fly exactly this way?

Yes. Rather big deal. For starters, up there we don’t have GPS positioning, which forms the central element of any autonomous flying on Earth. As an aside, in fact, on Earth GPS is also used for manual piloting for position and attitude control. Also, we might not yet have precise landmarks to calibrate the inertial guidance system, and performing such calibration would not be trivial autonomously. In Apollo, the astronauts performed this manually by using stars and planets as landmarks. And the location systems on Earth were so precise anyway that this manual calibration was at the end more or less only for validation and backup purposes. On Mars, obviously, all this is missing.

If you check out the map you see how NASA have constrained the area where they intend to fly their planned five missions. It’s a small limited patch, and appears to be pretty flat. Also, being a first proof of concept and technology, Ingenuity does not have any of the clever obstacle avoidance features found in many modern drones. I assume, apart for weight and power consumption reasons, also to keep the overall system complexity low. More complexity, more failure modes. Many more.

Failures – a whole additional can of worms in an autonomous system. Remember the infamous 1202 and 1201 alarms during the landing of Apollo 11? All error handling was delegated to the pilots on-board the lunar lander. And the pilots could communicate with ground control in real-time, and enquire about the alarms. Signals between the Moon and Earth take a second or two to travel the distance. On Mars, that is not possible, of course.

Detecting errors is relatively easy. The big challenge is how to handle them autonomously. In systems development we used to sloppily quip, “Never test for an error condition that you don’t know how to handle.” As all jokes, it contains a grain of truth. In Earth orbit, and even near or on the Moon, with literally hundreds of people busy in ground control, being able to quickly analyse a detected error, and then advise the astronauts on the further course of action, this is as straight-forward as it gets, as distressing this might have been during the first lunar landing.

But programming this into a completely autonomous flying machine is not as straight-forward as one might think. Software processes depend on each other, impact each other, and the same holds for electrical and mechanical components, and for all the interactions between the realms. The combinatorial complexity of possible system failures simply explodes, the decision tree becomes intractable. Also, an error correction here can easily lead to other problems over there. I just recently implemented autonomous error handling in my Oberon RTS system. After lots of “good ideas” and experimentation, I finally resorted to a relatively simple solution, always on system level, that is, not targeting single processes, with an escalation ladder of increasingly “harsh” measures in case the error persists, or another one has popped up in the meantime. The ultimate measure is to reload and reboot the system from the disk, which just takes a second or two, as the whole real-time operating system is smaller than 100 kB. But also repeated system reloads if some error persists have to be caught and prevented. And so on. As said, it’s a can of worms.

Bottom line, it’s no surprise that NASA’s engineers have kept the complexity as low as possible for this first attempt and test. Maybe machine learning could finally be put to some real beneficial use, not just to profile people on the web. Failure modes and their combinations could be learned and updated, together with the preferred corrective outcomes.

PS: yes it’s an engineer’s typical déformation professionelle to think in terms of feasibility, possibility, limits, and failure modes.