Hello Bitcraze,
My team and I have gotten multiple drones up and running with the TDoA anchors. However, one issue we've been having, even when using just 1 drone, is that the drones sometimes do not fly to the proper z locations that we choose. We at first suspected low battery to be the issue, as we know that the drones are supposed to slowly lower as the battery levels drop. However, we've seen the same behavior with full battery. We have tried replacing the rotors and rotor mounts as well, but still sometimes see this issue. Do you all know what may be causing this? Thank you!
Unstable hovering
Re: Unstable hovering
The Z hovering point is still a challenge. Making sure there is low vibration (with good motor and propeller) can help a lot.
The battery voltage is compensated for by the position control loop so it is normal you are not seeing a difference with full batteries.
The problem, as far as we can understand it, has more to do with vibration making it to the accelerometer and corrupting the Z acceleration measurement. This is why having less vibration helps. Some tuning of the Kalman filter can also help (changing the acc Z noise).
Are you seeing similar problem with TWR? Since TDoA is still experimental we have not tested it extensively and we think that there might still be improvement possible in the ranging sequencing: in our test system we have anchor 0 to 3 on the bottom and 4 to 7 on the top, since we are ranging in a sequence 0 to 7 we have TDoA measurement around Z only two times (from 3 to 4 and from 7 to 0), this might affect the Z ranging accuracy.
The battery voltage is compensated for by the position control loop so it is normal you are not seeing a difference with full batteries.
The problem, as far as we can understand it, has more to do with vibration making it to the accelerometer and corrupting the Z acceleration measurement. This is why having less vibration helps. Some tuning of the Kalman filter can also help (changing the acc Z noise).
Are you seeing similar problem with TWR? Since TDoA is still experimental we have not tested it extensively and we think that there might still be improvement possible in the ranging sequencing: in our test system we have anchor 0 to 3 on the bottom and 4 to 7 on the top, since we are ranging in a sequence 0 to 7 we have TDoA measurement around Z only two times (from 3 to 4 and from 7 to 0), this might affect the Z ranging accuracy.
Re: Unstable hovering
We are using TDoA right now. That last part, are you saying that maybe having different Z values for each subsequent anchor could improve accuracy? I think it would be worth a shot. I will try this this week hopefully. I also have not had a chance to try out the new feed-forward controller you all are testing. Is that providing any advantage in this realm?
Re: Unstable hovering
The non-linear controller seems to help a lot for following trajectory but I am not sure of how much it helps for keeping altitude. I would say it is better but I have not done much comparative tests.
For the anchor scheduling what you could try is to keep there position as they are but number them in zig-zag. Also on the other related thread I talked about the I part of the PID, it would be worth trying to add a bit of Integral to the Z PID position controller: I know that the kalman filter has an overestimated velocity output for Z.
For the anchor scheduling what you could try is to keep there position as they are but number them in zig-zag. Also on the other related thread I talked about the I part of the PID, it would be worth trying to add a bit of Integral to the Z PID position controller: I know that the kalman filter has an overestimated velocity output for Z.
Re: Unstable hovering
After a few sessions of testing, we found that the pose in RVIZ, which is showing the point that we tell the drone to go to, is dropping on some flights. We are not exactly sure why, but this is what has been causing our drones to have our Z axis issue. We again suspect is has something to do with the battery monitoring code. Do you have any information about this, and also how we could disable battery monitoring temporarily? I will try to upload a ROSBAG as soon as I can get one that demonstrates this problem, but it is intermittent and difficult to reproduce at times.
Re: Unstable hovering
What part of the battery monitoring are you suspecting to be the problem?
Re: Unstable hovering
I apologize if my understanding is wrong, but from what I can tell, the only thing in the default LPS code that could cause the actual setpoint of the drone to change at all is the battery monitoring code. Like I said before, the actual setpoint of the drone is dropping during SOME flights, and the only thing that I know that causes that for sure is the battery monitoring. I am just confused as to why this issue has not been seen by anyone else, and if it has, it hasn't been reported. I cannot test until tomorrow, but I will try to get a good rosbag for you, and maybe we can figure this problem out.
On a sidenote, how do you guys add waypoints for flight, like what you've done with a few of the videos you've posted?
On a sidenote, how do you guys add waypoints for flight, like what you've done with a few of the videos you've posted?
Re: Unstable hovering
For the setpoint it has been done with various software depending on the video. Basically we have 2 main system: ROS and the crazyflie python library. For maker faires we have been using ROS and a midi-to-setpoint bridge. Recent videos (including the one of this week blog post) have been done using the crazyflie python lib autonomous sequence example.
Re: Unstable hovering
Ahh okay, are there any plans to implement setpoints into the ROS code?
And here, I tried recreating the issue we had seen with the dropping pose/setpoint.Here is a rosbag of an attempt that was close to what we were experiencing. You can see the setpoint drops, and the drone drops with it. Here is the link
https://drive.google.com/open?id=0BzQzu ... VNSTVc4RUU
And here, I tried recreating the issue we had seen with the dropping pose/setpoint.Here is a rosbag of an attempt that was close to what we were experiencing. You can see the setpoint drops, and the drone drops with it. Here is the link
https://drive.google.com/open?id=0BzQzu ... VNSTVc4RUU
Re: Unstable hovering
I am having problem reading the Rosbag. Why is the extension .active?
For ROS and setpoint that has been done too. There is a ROS-node that allows to send position setpoint to the Crazyflie so it is pretty easy to implement a setpoint sequence. We have done it for a couple of demo, though I cannot find the code in any of our github for now.
For ROS and setpoint that has been done too. There is a ROS-node that allows to send position setpoint to the Crazyflie so it is pretty easy to implement a setpoint sequence. We have done it for a couple of demo, though I cannot find the code in any of our github for now.