Practical Problems

Issues during Algorithm shaping

Velocity Based Control Algorithm

  1. Oscillations: Since we are controlling the drone to make the velocity track a calculated safe velocity, the drone tries to accelerate as and when the velocity drops below the safe velocity which results in large number of oscillations.

  2. Stability: At the boundaries of the zones, the control action is maximum negative and this happens within one time step which would drive the real drone to instability. At the boundary the control action is aggressive, which is not desirable.

Distance and velocity based control

In this method, the past readings are taken into consideration. If drone is moving faster, the difference between two consecutive distance readings will be higher. In this case, speed of drone should be reduced faster by increasing negation factor. For detailed description refer final report. This approach had the following issues:

  1. Oscillations: If at any point, control action is negative that is pitch/roll angle is opposite to previous value of pitch/ roll angle, velocity at that instance becomes negative. This actually increases negation factor. Due to which a lot of oscillations are introduced. Sometimes drone went unstable due to aggressive corrective action. The solution was to remove the dependency on velocity.


  1. Reduction factor used for stopping the drone should be as linear as possible and preferrably only dependent on distance from the wall.

    This observation was used to develop the final algorithm which only depends on distance from the wall and the angle at which the drone is travelling.

    To arrive to this solution, we analysed flight logs of working drones. These logs are available as data with the report. The logs showed that with increase in pitch/roll angle the speed increased linearly and vice versa.

    A doc with flight data is available here.

    One more observation that was interesting was that to stop a drone going at an angle of X , a retarding force equal to negative of X is sufficient.

Distance Based Control

This is the final algorithm we are using for this challenge. This algorithm works good to stop the drone from chrashing but has some drawbacks:

  1. The speed of the drone needs to be controlled. This is a requirement more than a problem. In closed spaces, if the drone moves with high speed and with short range of sensor readings, it is impossible for the drone to stop before hitting the obstacle. Speed and safety of the drone are inversely proportional and we had to tradeoff one of them to increase the other.

    So, we have tried to keep the speed high with complete control on the drone.

    Also, the flexibility of our algorithm provides scope for changing this very easily (using Negation Factor)

  2. Small oscillations near the obstacle. When the drone approaches an obstacle, it has damping oscillations before settling down. This is an issue we could not entirely resolve, but the oscillations can be damped to quite an extent by calibrating the constants in negation factor, as explained below:

    Negation Factor = m* (angle/ (distance from wall +c))

    where, m and c are constants that can be calibrated to get drone to work at different speeds.

    Retardation of drone is directly proportional to the negation factor. Therefore, more the negation factor, faster will the drone slow down. This gives us liberty to alter maximum operation speed. So, at higher speeds the value of m increases and the value of c can be used to fine tune the distance from the wall at which the drone settles down. The values can be calibrated. A few examples of effect of these values is given in the table below:

    m c Maximum operating angle Closest distance from wall
    1.1 2 18 degrees 0.3 m
    2 1 18 degrees 0.4 m
    1 0.2 8 degrees 0.3 m


The simulation is available here.

To set up Joystick control for MATLAB. Refer this.


Manual for setting up BeagleBone can be found here.

An issue we faced while sending and receiving UDP packets to and from Beaglebone was: Datatype mismatch between matlab and beaglebone. Since different machines may use different floating point representations, sending float values as 'float' was not a good idea. The data received may not match the data sent. One way to solve this is to send data as text. Another way is to send them as integers. In our code, we have multiplied all float values by 100 and send them as integers. On the control code in beagle bone, all values are divided by 100 to get the actual data. One problem with this method is that the precision of floats is upto two decimal places.

Suggestions for Spring Semester

We have one suggestion to make for the Spring semester. The need for a altitude hold to prevent drone from changing altitude when the operator is not changing the throttle values. During simulation we observed that the drone has the tendency to change altitude when it approached the obstacle. This change is not much but it would be great if we can have a altitude hold. It would give the drone better stability.