Firefly Eindhoven - Control and Coordination

DRAFT

The drones are controlled with the Simulink files, which contains the following components:

• Avular’s low level control

• Communication block

• State machine controlling drone’s mode (i.a. landing, take off sequences, manual fly)

• High level control

• Sensor fusion with state estimation

All of the before mentioned blocks except the Avular’s low level control are available for the team’s changes. The most frequently changed blocks are the high level and communication blocks.

The high level controller is responsible for producing the reference angles pitch, roll and yaw based on the state and the desired position/speed references. The team has two strategies for the high level controller, which are covered after the components’ description. However, it has to be emphasized for the future users that in the Simulink file the position reference field fuses the manual flying mode with the high level controller, therefore modifying the connections within the field has to be done carefully.

The communication block is modified whenever it is needed to see new signals sent back to the PC running visualization or when new data is to be received by the drone during flight. For instance very useful application is to modify the high level PID control gains during the flight or to plot the controller’s action along with the reference errors. This way two control strategies can be compared at the same time before even using them (control actions are only sent to visualize, but are not fed to low level control).

The state machine has not shown any problems that would introduce the need for modifications, however, the state machine controls the automatic sequences responsible for landing and takeoff. Currently the sequences are conducted via feed forward in speed for a specified amount of time (the times strongly differ between the drones!). It is recommended to uses the position estimation as the wrong time settings cause the drone to fall. Furthermore it is crucial to verify the LIDAR and accelerometer readings before any takeoff. Lidar obstruction leads to reaching height limits and noisy accelerometer’s readings indicate poor initialization of the low level control and direly affects the drone’s behavior. To prevent simple but dangerous errors in script modifications it is very important to always saturate the references fed to the low level and the height references used.

Trajectory tracking

This strategy is the basic method used by the team to conduct the show with the drone. All reference points are stored on the drone’s memory and are fed to the high level controller. The rate with which the points are fed to the controller can be tuned with the gain defined by the user in the simulation, however, it is also proportionally dependent on the rate of the CPU and of the simulation. Therefore it must be emphasized that points’ density and simulation frequency affect the speed of the trajectory directly. The main advantage of the trajectory tracking is simplicity, however, it is highly susceptible controller tuning. With poor controller the drone may skip parts of the trajectory when lagging behind, have significant overshoot or oscillate around points within the trajectory. So far the team has been able to achieve satisfying results and perform a show at the event with moderately tuned controller. It has been noticed that feed forward and lower derivative gains of the high level controller improve significantly the performance of trajectory. The position measurements show that shapes like circles are particularly difficult for the trajectory tracking resulting in ellipses. This is probably due to poor speed estimation when working with the decawave positioning system. Overall the tests have shown that trajectory tracking strategy suffices for the current speed and shape of the trajectories designed for the Glow event. [show results below]

Path following

The path following strategy is a strategy based on the speed control. The supervisor knowing the estimated position of the drone finds the closest point at the trajectory and undertakes two control actions. It calculates force tangential to the trajectory based on reference speed associated with the previously found trajectory index. Secondly it calculates the force towards the trajectory to reduce the deviation from the desired position on the trajectory. This strategy was mainly tested on the ground robots due to instability during the flying tests and different priorities. After two attempts of introducing the path following with the drones it has been asserted that this strategy is too sensitive to noise in the speed estimation. It is recommended to try out this strategy after dealing with the noise e.g. by applying filter to the decawave system as the results with ground robots have shown much better tracking performance with the path following method.

Collision avoidance

Currently still tested approach is the repulsive force method. Based on the distance from the estimated position and the undesired point (static obstacle or other drone) the repulsive force is calculated. The unit vector calculated as the repulsion direction is scaled linearly with the distance(inversely proportional), proportional gain and is divided by the range at which the collision avoidance should start acting. The proportional gain defines the slope of the relation, however, it should be noted that the maximum force is saturated after adding forces with the position control’s action, thus currently it is not designed to deal with operation in saturation.