Assignment

A note on the meaning of "panic"

The following might prove to be a little confusing. In this lab manual, we will refer to something called "Panic mode". This is a mode in which the drone can be, which carefully brings the drone into a safe state, and then automatically switches to "Safe mode" when such a safe state has been achieved. To bring the drone to a safe state in panic mode you will have to for example, spin down all the motors.

This is entirely separate from the Rust concept of code panicking. When Rust code panics, there is generally not much you can do to keep running and keep your drone in the air. You might want to gracefully shut down your motors in your panic handler as a safety measure, but it's totally separate from "Panic mode".

So to reiterate one more time:

• "Panic mode" refers to one of the multiple modes the drone can be in
• Rust code panicking means that some kind of unrecoverable error like an index-out-of-bounds or integer underflow occurred in your code

The team assignment is to develop (1) a working demonstrator and (2) associated documentation (a report) of a control system, based on the quad-rotor drone available. In an uncontrolled situation, the drone, inherently unstable, will almost immediately engage in an accelerated, angular body rotation in an arbitrary direction, which typically results in a crash within seconds as an unskilled human will not be able to detect the onset of the rotation quickly enough to provide compensatory measures with the joystick. The embedded controller’s purpose is to control 3D angular body attitude (φ, θ, ψ) and rotation (p, q, r), as defined in the Theory of operation and Signal definitions. This implies that the body rotation will not just uncontrollably accelerate, but will be controlled by the embedded system according to the setpoints received from the joystick (specifying roll, pitch, and yaw). In effect, the embedded system acts as a stabilizer allowing a (slow) human to manually control drone attitude using the joystick.

The lab hardware available to the team are:

• a twist handle joystick,
• 2 test boards, including the microcontroller and sensors
• a drone

You are expected to have a computer running linux to program the board and to fly the drone. It might be possible ot use other operating systems or VMs for this course, but it's not well-tested, so be prepared for some troubles to set that up.

The drone shall be controllable through the joystick, while a number of parameters shall be controlled from the PC user interface. The status of the system shall be visualized at the PC screen, as well as on the drone (using the 4 LEDs on the flight controller board). Whereas the hardware is provided, in principle, all software must be designed by the team. Code on the Linux PC and drone shall be programmed in Rust. A description of the required system setup, together with the signal conventions appears in the Signal definitions.

Safety Requirements

Although the project intentionally has some degrees of design freedom, the following requirements must be fulfilled. The first set of requirements relate to safe Quadrupel operation such that this valuable piece of equipment is not damaged:

• Safety The ES must have a safe state (for drone and operator) that shall be reached at all times. In this state, the four motors are de-energized (zero RPM). This shall be the initial state at application startup, as well as the final state (either at normal exit or abort). Consequently, joystick states other than zero throttle and neutral stick position are illegal at startup, upon which the system shall issue a warning and refrain from further action. Note, that the safe state is not to be implemented by merely zeroing all setpoints at the PC side as this does not guarantee that the ES (when crashed) will be able to reach this state.

• Emergency Stop It shall be possible to abort system operation at all times, upon which the system briefly enters a panic state, after which it goes to safe state. In the panic state rotor RPM is set at a sufficiently low rate to avoid propeller damage, yet at a sufficiently high rate to avoid the drone falling to ground like a brick causing frame damage. Panic mode should last for a few seconds until it can be assumed that touch-down has occurred, after which the drone must go into safe state. Aborting the system must be possible by pressing joystick button(s), and keyboard key(s) (see the Interface requirements)

• Battery Health The LiPo batteries powering the drone need to be handled with care as draining them will inflict fatal damage. In particular, the battery voltage should never drop below 10.5 Volt. As soon as the battery voltage (read out over the internal ADC) crosses the threshold, the drone should enter panic mode. Preferably, the pilot should be warned ahead of time, so they can land safely without the risk of getting his flight aborted at an inconvenient moment.

• Robust to noise As sensor data is typically noisy and may contain spurious outliers, feeding raw sensor data to the controllers may result in large variations of the four rotor control signals ae1, ae2, ae3, and ae4, possibly causing motor stalling. The on-board sensing module (InvenSense MPU-6050) therefore includes a Digital Motion Processor (DMP) that filters and fuses the raw accelerometer and gyro readings to arrive at a smoothed stream of attitude readings. Note however, that in the final stage of the project, the filtering must be done “by hand” on the microcontroller itself and care must be taken to remove obvious outliers and filter vibration noise such that the sensor data is sufficiently stable and reliable to be used in feedback control¹

• Reliable communication The PC link must be reliable, as any error in the actuator setpoints may have disastrous consequences, especially when the drone has lift-off. A wrong rotor RPM setpoint may immediately tilt the drone, causing a crash. Note that dependability is a key performance indicator in the project: a major incident that is caused by improper software development (i.e., improper coding and testing) may lead to immediate disqualification. Testing communication status at both peers may involve sending or receiving specific status messages to ascertain that both peers are operating and receiving proper data.

• Dependability The same dependability standards apply to the embedded system itself. If, for some reason, PC link behaviour is erratic (broken, disconnected) the code should immediately signal the error and go to panic mode

• Robustness Last but not least, the embedded control code must be as reliable as possible. An important aspect is the proper use of fixed point arithmetic for representing and handling of sensor values, filter values, controller values, various sorts of intermediate values, parameter values, and actuator values (the Cortex M0 processor does not provide floating-point arithmetic instructions). On the one hand, the values must not be too small, which would cause loss of precision (resolution). On the other hand, the values must not become too large, as this may cause integer overflow, with possibly disastrous consequences.

Functional Requirements

The next requirements relate to proper functionality of the ES. As mentioned earlier, the ES is intended to act as a controller that provides an order of stabilization to the drone attitude and rotation, such that the drone can be adequately controlled by a human. The requirements are as follows:

• PC The PC shall act as the user’s drone control interface. After verifying that the joystick settings are in neutral, it shall upload the ES program image to the drone (which at that point runs a simple bootloader that waits for a valid program to execute), read inputs from the keyboard and the joystick, send commands to the ES, read telemetry data from the ES, and visualize and store the ES data. At mission completion (or abort) the PC shall set the ES in the safe state, have the ES program terminate, which returns control to the bootloader that will wait for the next program to run.

• Drone The ES shall be operated in at least six control modes, safe, panic, manual, calibration, yaw control, full control, raw, height and wireless are optional. In all modes except for safe and pani, the joystick and keyboard produce the control signals lift, roll, pitch, and yaw (see the Interface requirements for the joystick and keyboard mappings). The demonstrator shall commence in safe mode at startup. A flight experimentation sequence always starts with selecting the proper mode, prior to ramping up motor RPM.

  • Safe mode In safe mode, the ES should ignore any command from the PC link other than the command to either move to another mode or to exit altogether. Effectively, the ES should keep the motors of the drone shutdown at all times.

  • Panic mode In panic mode the ES commands the motors to moderate RPM for a few seconds such that the drone (assumed uncontrollable) will still make a somewhat controlled landing to avoid structural damage. In the panic state, the ES should ignore any command from the PC link, and after a few seconds should autonomously enter safe mode.

  • Manual mode In manual mode the ES simply passes on lift, roll, pitch, and yaw commands from the joystick and/or keyboard to the drone without taking into account sensor feedback. Note that the keyboard must also serve as control input device (for instance, pressing ’a’ increments lift, pressing ’z’ decreases lift), such that the actual commands being issued to the ES are the sum of the keyboard and joystick settings. This enables the keyboard to be used as static trimming device, producing a static offset, while the joystick produces the dynamic relative control component. Also see the Interface requirements which prescribes the key map that must be used.

  • Calibration mode In calibration mode the ES interprets the sensor data as applying to level attitude and zero movement. As the sensor readings contain a non-zero DC offset, even when the drone is not moving, the calibration readings thus acquired are subsequently stored during subsequent mode transition to controlled mode, and used as reference during sensor data processing in controlled mode.

  • Yaw-controlled mode In yaw-controlled mode the ES controls drone yaw rotation in accordance with the yaw commands received from the twist handle. In this mode, the joystick control mapping is the same as in manual mode, except for the twist handle (yaw), which now presents a yaw setpoint to the yaw controller. The yaw setpoint is yaw rate (cf. r). Neutral twist (setpoint 0) must result in zero drone yaw rate (r = 0). Unlike in manual mode, drone yaw should now be independent of rotor speed variations as much as possible, i.e., when the drone starts yawing the ES should automatically adjust the appropriate rotor thrusts ae1 to ae4 to counter-act the disturbance. As the yaw sensor may drift with time, an additional trim function (through keyboard keys, see the Interface requirements) must be supplied in order to maintain neutral twist - zero yaw relation. In this mode, the relevant controller parameter (P) should also be controllable from the keyboard (Interface requirements).

  • Full-control mode In full-control mode the ES also controls roll and pitch angle (φ, θ), next to yaw rate (r), now using all three controllers instead of just one. The same principles apply: neutral stick position should correspond with zero drone roll and pitch angle. As the drone has a natural tendency for rapidly accelerated roll and pitch rotation (it’s an inherently unstable system), proper roll and pitch control is absolutely required in order to allow the drone to be safely controlled by a human operator. Similar to the yaw control case, proper roll and pitch trimming prior to lift-off is crucial to safely perform roll and pitch control during lift-off as the vehicle has a natural tendency to either pitch or roll due to rotor and weight imbalance. For the keyboard map of the roll and pitch trimming keys see the Interface requirements.