Chrono in Unreal, part 7: The drone

The drone provides the third view of the demo. It was a kinematic actor at first, following a path, with a camera fixed to the airframe. The picture did not look like a drone’s: no lean under acceleration, no holding against the wind, and when it pitched its own rotors swung into the frame. Now it is a Chrono® body with four rotors and a controller, and the choreography only provides setpoints. This part describes the model, the controller, the handling of the setpoints and the battery model. The series: part 1 overview, part 2 architecture, part 3 traps, part 4 sound, part 5 picture, part 6 parasail, part 9 sequence.

The demo the series is about. The drone view bottom right. On YouTube in 1080p the console is readable.

The body

A quadcopter of 1.5 kg, 22 cm arm length and a collision sphere so it can collide with the vehicle. Each rotor gives a thrust proportional to the square of its speed along the airframe’s vertical axis, acting at the rotor, and a reaction torque proportional to the thrust with alternating sense. The thrust constant is chosen so that four rotors at hover speed carry the weight. The speed follows its command with a motor lag of 50 milliseconds. Added to that, air drag against the airflow from own velocity and wind, and a light rate damping.

That makes the drone an underactuated system like a real quadcopter: it can only push along its vertical axis and has to tilt to accelerate sideways or to hold position in the wind. The picture shows that tilt, and the camera under it has to compensate.

The controller

The controller is a cascade from the setpoint down to the four rotor speeds:

1. From commanded position and velocity a velocity demand, from the velocity error an acceleration demand, limited horizontally. While filming the limit is lower, so the camera stays calm.
2. Acceleration demand plus gravity gives the thrust vector. Its length is the total thrust, its direction the desired vertical axis. Together with the desired camera heading that yields the desired attitude as a rotation matrix.
3. The attitude error is formed geometrically on the rotation group, e_R = ½ vee(R_dᵀR − RᵀR_d), and the moment is M = −k_R e_R − k_ω ω + ω × Jω. The gyroscopic term compensates the coupling of the axes; the two gains are attitude and rate.
4. A mixer distributes total thrust and three moments onto four rotor thrusts, each limited between a minimum and the maximum, and the commanded speed follows from that.

The geometric formulation instead of Euler angles has a practical reason: the backflip. It is written as a pitch reference about the lateral axis running through 180 degrees, with a short thrust pulse before it. A controller with Euler angles breaks down at 90 degrees of pitch, the geometric one does not, and the drone follows the reference with its rotors, which turns the picture over once.

Setpoints that can be flown

The choreography, intro, orbit, ball chase, low flight to the dune crest, dive to the parasail, formation flight, return to the vehicle, knows only setpoints. The first version handed these points straight to the controller. A jump in the setpoint, because the terrain ahead differs or a target changes, thereby became a jump in the rotor forces: the drone braked, hopped and swung after. That was visible in the picture, and the developer named it: “the drone stops several times and swings”.

The setpoint now runs through a follower with a speed and an acceleration limit per flight phase, horizontal and vertical separately. The desired speed towards the setpoint follows a braking profile v = √(2 a d), so the drone decelerates early and steadily instead of braking hard at the target; near the target the profile changes into a proportional approach. A velocity loop with the acceleration limit executes it. Where the target moves, the vehicle in the intro, the ball, the canopy in the dive, its velocity is fed forward. Without feed-forward a follower lags a moving target by speed divided by gain, and in the dive the drone never caught up with the canopy. The follower has one more feedback from the physical body: the setpoint may not run further below the real drone than a catch limit, otherwise the controller drags the drone after the setpoint into the ground, and at the start the drone fell through the sand. The limit was 0.2 metres everywhere at first, and that wrecked the descent at the beginning of the demo: in the acceleration phase the setpoint had to wait for the drone, the descent came in bursts averaging under a metre per second and was not down after the 15 seconds of intro. Now 0.2 metres holds in the last three metres over the ground, where the fall-through happens, with at most 1.5 metres per second of sink rate, and one metre above that; the descent is steady again at 3.5 metres per second.

In the low flight over land the pace is planned, not throttled. The first version shed speed before every rise in the look-ahead, and the drone crept over gentle hills at 6 metres per second; the developer wanted it to chase and think ahead while doing so. Now the drone samples the terrain every 10 metres out to 150 metres ahead. Every slope limits the speed at which it can be flown over with the available climb rate, climb rate divided by grade, and the braking distance says how fast the drone may still be now to reach that speed there: v ≤ √(v_k² + 2 a d_k). The minimum over all samples is the plan. Flat ground and gentle hills cost nothing, a steep slope is approached slowed down, and the drone travels to the crest at 17 metres per second where it flew at 6 before. The height follows the ground 45 metres ahead with a clearance that is larger over water and near the vehicle, because of the jetty. Independently of that, a minimum height over the maximum of terrain and sea level holds in every phase except the landing. The terrain function returns the seabed under water, and without the sea level condition the drone planned its departure from the sunk vehicle 2 metres under the surface.

The gimbal

The camera wants to look at its focus point. Relative to the airframe it may pitch 90 degrees down and 30 up and roll 15 degrees; it compensates the airframe’s tilt only within these limits. Beyond them it sits against the stop and the picture tilts with the airframe, as a real gimbal does. The HUD shows the stop. The drone’s own actor is hidden from its own camera, otherwise the rotor disc swings into the frame from above. On the water, after the shutdown, the gimbal is off and the camera hangs fixed to the airframe.

The battery decides the end

The battery model turns the drone into the demo’s timer. The power of each motor goes with the cube of its speed, after the propeller law, plus a constant power for flight controller, camera and video link. The open-circuit cell voltage is a function of the state of charge, a curve with the flat middle and the knee under 20 percent, and the terminal voltage is the open-circuit voltage minus current times internal resistance. The current follows from power and terminal voltage, and the charge drawn lowers the state of charge. Two things follow that a simple counter would not have: at a low state of charge the same power needs more current, and the voltage sags under load. The battery is visible in the HUD with voltage, current and state of charge.

On the crest the drone does not stand still. After the turn it flies a slow circle of 12 metres radius, one lap per minute, the view held over the island, until the dusk sends it to the canopy. An attempt to send it to the canopy at once shifted the end: circling the canopy costs more than circling on the crest, and the battery was at 15 percent before the boat reached the beach.

The end of the demo hangs on these numbers, not on a clock. At 15 percent the drone breaks off the formation flight and flies back to the sunk vehicle, eight metres from it towards the jetty, 2.5 metres over the water. At 10 percent the forced landing begins, a slow descent at 0.4 metres per second. The motors only stop once it sits on the water. From then on no controller acts, only gravity, air drag, buoyancy and damping in the water. The controller without thrust had produced an invalid attitude in one run, and since then a guard restores the last valid pose on an invalid state. In the water the electronics keep drawing, strobe, camera, radio and the wet controllers; at 8 percent the drone shuts down, and two seconds later the demo ends. In the shown run the state of charge reached 15 percent after 487 seconds of flight; with the chosen capacity and power values that is the flight time of a small camera drone. The capacity was set from 2.6 to 2.86 ampere hours at the end, ten percent more. The reason is the vehicle: after the emergency stop on the beach it stands, backs up and only then drives on, and that time was missing for the drone at the end. The cleaner remedy would be to block the back-off after an emergency stop; the pragmatic decision was the bigger battery.

At night

As soon as it gets dark, the drone flies a formation around canopy and boat, a circle around the midpoint of the two at 9 degrees per second with a wide field of view, so both stay in the frame. Added to that the strobe, a double flash per second, as the boat lights do. The developer asked for both, the circle because the drone “dawdled in the dark”, and the light so it can be found in the vehicle’s picture.

What the model costs

One body, four forces, a controller with a few matrix operations per substep. The physics time did not change measurably. The effort went into tuning the setpoint handling, not the model, and for a camera drone that is the right place: the model only has to be correct, the handling has to look good.

What the picture of the night consists of, with strobe, searchlight, moon and stars, is in part 8.

Keywords: quadcopter simulation Chrono, geometric attitude controller SO(3), drone Unreal Engine physics, setpoint follower acceleration limit, battery model internal resistance state of charge, gimbal end stop simulation, camera drone choreography, serious gaming, simulation consulting Switzerland, swissEmbedded

Unreal® and Unreal Engine® are trademarks or registered trademarks of Epic Games, Inc. in the United States of America and elsewhere; these articles are neither endorsed nor reviewed by Epic Games. Project Chrono is an open-source project of the University of Wisconsin-Madison and Politecnico di Milano under the BSD-3 licence.