LPS not giving proper position of drone

[sali0]

Hello all! My team and I have been trying to put together the LPS to proceed with our project, but we have not been able to get a drone hovering. We have tried everything we can from the tutorial on the wiki and have become completely lost at this point. We have set up the anchors about 2 meters apart in all kinds of different orientations, to try to get a proper picture of our drone inside RVIZ, but every time we set the system up, the drone appears in a completely different place than what it actually is. We have the drone set in the middle of all the anchors, but the drone appears meters away outside of the space we have set up. Here is a picture demonstrating what we have gotten:

as opposed to what it looks like in actuality (Anchors marked with black circles). .

Has anyone else experienced this? We have confirmed our axes to be correct, and have the drone facing in the correct direction. We have tried staggering the anchors, with different z positions on them, but we always get the same results. And so far, it seems like no one else has gotten these errors. We could really use some help! Thank you all.

[justinleeyang]

hi,sali0:

I think that you should be install the LPS node to 3D printf holder. that is:

33333.jpg (153.8 KiB) Viewed 5895 times

Place the anchors at least 15 cm from the wall or ceiling, and preferably at least 2 meter apart.
then dwm1000deck measure distances will be more precise with 6 anchors.

[sali0]

Hello Justinleeyang! Thank you for the reply. We are still trying to get the 3D printed mounts printed, but will take some time. But can we not have the anchors perpendicular to the floor to immitate how the mounts hold them? We will hopefully try this this Friday, and I will check back. Thank you!

[arnaud]

Hi,

A wrong position like you are seing actually look like a wrong anchor position information. Does the anchor position matche and is correct? one possible mistake is that the anchors have address from 1 to 6, and the position of the anchor with address 1 is set as anchor0_pos in the ros configuration (will be changed next time I do a howto video ... the anchor will be addressed 0 to 5).

[sali0]

Hello Arnaud! We set up our anchors exactly how it says in the wiki:

Anchor0 in ROS will be the anchor with address 1. Anchor5 in ROS is then the anchor programmed with address 6. This is because the anchors are addressed from 1 while the ROS implementation starts at 0. The inconsistency will be fixed in the future by addressing anchors starting by 0.

We have our anchor0_pos as the anchor 1, and so on until anchor5_pos as anchor 6. Is this not correct?

[arnaud]

This is correct and it should work.

Can you launch the dwm_loc_ekf_hover.launch launchfile and record a rosbag (with "rosbag record -a")? If you upload the rosbag somewhere we can look at it and maybe see what is going wrong.

/Arnaud

[sali0]

Hello Arnaud. We have tried once again with a different anchor setup but we were again not able to get it to work properly. The bag file is here http://www.filedropper.com/2016-11-25-17-42-00. I do not know if I recorded the bag file correctly, as I had to manually stop the process for it to complete. Please let me know what you think. Thanks!

[arnaud]

Hi, Thanks for the rosbag. From it I can see that the ranges coming from the LPS are all at 0, this certainly where your problem is coming from.

What is the state of the LEDs on the Crazyflie LPS deck and on the Nodes? If things are communicating as expected you should see the 4 LEDs blinking.

[sali0]

Hello!
Apologies for the (very) late reply, but we have finally got back to testing the system, and have made a cube out of pvc for a better, more reliable setup process. However, we are still getting the same errors. The drone is drifting far off into the distance each time we initiate the dwm_loc_ekf. We checked the LEDs on each of the anchors when the drone is in the middle of the x and y axes at the bottom of the cube, and 3 of the anchors did not have TX blinking. However, moving the drone closer to Is this a hardware issue, and is there any way to test the anchors individually? Thank you.

[arnaud]

Hi,
Do you have the latest version of both the Crazyflie firmware and the LPS-Node firmware? There has been a communication bug a little while ago that has been fixed. This could be your problem.

You can test the anchor individually by looking in ROS for the ranges topic. With rqt_plot you can plot the range to each anchors to see if they behave correctly (ie. if the range gets smaller when the Crazyflie approach one anchor. You can also get an idea of the update rate since the values are updated only when a ranging is successful.