I've managed to implement a LQ-regulator for the crazyflie. I calculate the feedback matrix on the client and send this matrix and the setpoint to the crazyflie. There I calculate according to the actual gyro data and euler angles the necessary control for the motors. This works.
Now I want to shift the calculations of the motor ratios also to the client. Therefor I have to log the gyro data and euler angles. My logging period is about 2ms at the moment (this should be sufficient for sure). The calculated motorratios are send every millisecond to the crazyflie*. But for some reasons my regulator doesn't work. Right now I don't see any bugs in my code. So I thought that maybe the logged data causes the problem? Does anyone know how "up-to-date" the logged data is? Can I be sure that the logged data was measured at most (say) 4ms ago, if the logging period is about 2ms? Or can there occur for some reasons a bigger delay?
Update:
Now I'm sending the motorratios and an ID to the copter. Additionally I log this ID on the crazyflie. Then I meassure the duration from "sending an ID" to "this ID is back on my pc by logging it". The average duration is about 6ms.
So my logged sensor data are in average at most 6ms old. To be honest I don't really think that should be a problem. So maybe there are some bugs in my regulator which runs on my pc!?
I'll try my working regulator (sending the feedback matrix to the crazyflie) and calculate on the crazyflie the motorratios with 6ms old sensor datas. If it works I know that there is something wrong with my "pc-regulator".
Last edited by CrazyGuy on Wed Oct 14, 2015 8:42 am, edited 2 times in total.
I measured the latency from crazyradio to Crazyflie 2.0 once, it is 1ms at 2Mbps without retry (excluding USB). If you are at 250Kbps it can explain part of the latency. Assuming USB will add up to 1ms you should expect at a best case of 4ms round-trip latency.
As for the log it is sampled as when sent. I think the log is limited to 100Hz max but this can be hacked in the firmware (I guess you did it already).
Controlling at so low level from the ground is ambitious. Good luck and please keep us updated, this is an interesting project.
Update:
Calculating the motorratios on the crazyflie with 6ms old sensor data results in a little bit better result than calculating the motorratios on my pc with logged (actual) sensor data. But still: in fact you can't fly with it. You can only use it to take off...
Even with 2ms old data the crazyflie is very instable. At least you can fly it more or less. So it seems like I really need the sensor data as up-to-date as possible
Thanks for the update, this is really interesting!
We always thought it would be very hard to make a control-loop on the ground, now we have some proof.
We are actually working at moving more control in the copter: we believe we would get better positioning performance if the position loop is in the Crazyflie as well (for use with camera or local positioning).
Btw, why did you want to move the calculation on the ground, did you have any specific use case?
I want to track the crazyflie with 2 cameras. With the resulting 3d-coordinates I want to realise:
- LQ-regulator for the 12 dimensional quad-dynamics (position, velocity, euler, gyro)
- regulator based on model predictive control (12 dim)
For the mpc approach I need an optimal control problem solver which runs on the pc.
The "disadvantage" of calculating the controls on the crazyflie is: According to which regulator I use, the command-packages have to be defined differently (pid: desired euler and thrust. lqr: desired euler, thrust and feedback matrix. for the 12 dim regulator there would be also actual and desired position, velocity)
So I thought it would be prettier if I only have to send the motorratios. Then the command packages would always have the same pattern. Additionally this would allow me to switch the regulator while flying.
Whar you are looking at is exactly what we have been looking at lately. We know that the commander is too rigid and we want to make it more dynamic.
One thing we have been talking about is to add a "type" byte at the beginning at the commander that would describe the type of data contained in the packet, the stabilizer in the Crazyflie could then use this info (type of command and data) to run the appropriate stabilization algorithm. Is that something that sounds good to you? If so we can start designing the packet together so that it at least fits your needs.
