Dropping Packets when setting parameters
Bug Description
The ground station will attempt to set a parameter on the drone. If you then wait a while, and get the parameter, you should expect to obtain the parameter. Instead, what sometimes happens is that no parameter is obtained, and the control loop of the drone in the terminal just stops. If you then try to set any other parameters, or to apply setpoints nothing occurs. Sometimes the setpoint will get activated when killing the control loop.
Steps to reproduce
- Used drone 3.
- Used crazy radio 4.
- Tuning pitch attitude.
Crazyflie PID values. Follow lab manual and setting parameters. Yaw: kp = 1500
Pitch: kp = 500-> maybe lower
Roll: kp = 500 kd = 20
Attitude: Yaw: kp = 500 kd = 20
Pitch: kp = 100 kd = 50
Make sure you set sys->ess to 0.
The expected outcome is something like this.
However what often happens is that this doesn't work. For some reason the sw is trying to make a liar out of me and not show this issue, however it definitely exists, it might just take a while to get to.
Proposed Fix
Determine a way to get a "handshake" signal to work between the ground station and the characteristic of the bluetooth chip. The drone should only send a signal when a signal is requested. I think what may be happening is that the values in the bluetooth are not getting completely written. So there should be some type of confirmation that ensures the signal received is as intended. Furthermore, if a blank value is returned upon a "get" parameter request, it shouldn't crash the whole program. I'm guessing the sw just doesn't know how to handle whatever it is seeing.
Not sure if any of this is right.