Bitcraze Forums

Hello.

I am banging my head on the wall like my crazyflies but I fail to make it run.

I use 6 anchors at the following positions ( note the anchors are more than 1m from the walls ).

anchor0_pos: [ 0.0, 0.0, 2.25]
anchor1_pos: [ 2.5, 0.0, 0.10]
anchor2_pos: [ 5.0, 0.0, 2.25]
anchor3_pos: [ 5.0, 4.0, 0.10]
anchor4_pos: [ 2.5, 4.0, 2.25]
anchor5_pos: [ 0.0, 4.0, 0.10]

All anchors are flashed with the latest version. I tried normal anchor mode and TDOA mode.

As I want to use the crazyflie in a théatre performance, I started with the python scripts, my goal is to later be able to create choreography in Unity3D and control the crazyflie by sending OSC x,y,z positions to a python script.

But it failed...

So I installed ROS to be able to see the estimated position of the crazyflie.
in non tdoa mode, it rarely stabilize. and coordinates are sometime random. In TDOA, the coordinates are jumping and staying to 10.0, 10.0
Is it possible that 1 anchor is causing problems?
How to avoid that wrong position estimation are sent to the kalman filter?
Is it possible to show in Ros or Python Client the estimated distances?
I also see that the Kxd, Kxi, are 0

So what could be wrong?

Thanks in advance.

Vincent.

I am having the same errors. and also banging my head against the wall.

Hi vpaesmans ,

Unfortunately my experience shows that head-banging on the wall is rarely working against Crazyflie-wall-banging , sorry you are having troubles.

First of all TDoA is very experimental and will work best with 8 anchors since you need to start, and stay, within the convex hull formed by the anchors. I got them to fly with 6 by basically using the same anchor placement as you do (but smaller) and by starting the copters with pre-programed anchor position in the middle of the space at 50cm height.

I will try to answer the questions in order:

Is it possible that 1 anchor is causing problems?

One anchor could make the position unstable, but more often than not it will just "offset" a static position and make it move erratically when you move the copter.

How to avoid that wrong position estimation are sent to the kalman filter?

This is supposed to be done in both TWR and TDoA. Can certainly be improved but there is already code for it.

Is it possible to show in Ros or Python Client the estimated distances?

Yes, if you mean the measured distances. And this is my main advice to debug the system in Two Way Ranging mode. you can display the ranges in ros with "rostopic echo /crazyflie/log_ranges" and in the client you can setup a log block and plot the ranges, they are accessible via the log subsystem with these names: https://github.com/bitcraze/lps-ros/blo ... launch#L28. The last value, ranging.state, is a bit-field that indicates if any of the last 6 ranging attempt was successful for the anchor.

One random though of thing to check is the anchor address, in TWR it should start at 1 (I did put a warning about that in the wiki).
One other thing is that we where shooting a short xmass video yesterday and it seems that the EKF from 20-ish days ago was more stable that the one in the current master branch. You can test with the commit 574d43dd6ab999 of the Crazyflie-firmware. Please update us if it helps, we have not had time to investigate that too deeply.

I hope it helps.
/Arnaud

Two of many questions I have: (but will try to answer my own as much as possible and report back.)
So I need to set the anchor addresses 1-6 for TWR and 0-5 for TDoA?

Does the anchor attitude matter?
I have them on stands hanging upside down on ceiling and standing vertical on floor, the LED's point inwards towards the convex hull.

Hi Nate,

You are correct for the address. Eventually when TDoA is stabilized we will set them all to 0-5 but for now it is 1-6 for TWR and 0-5 for TDoA.

For the orientation we know there is a week spot of the antenna right in front of it in the plan of the board. So your placement looks correct to me, this is what I am usually doing.

Hello Arnaud.

Thanks for your help.

As you see in the topic change, the drones are dancing now...
I used another crazyflie and turned the anchors to the center and I get better stabilization and can now control them. Just have to get used to ROS.

I tested with both TDoA and TWR with addressing starting with both 0 and 1.
I'll recheck with the previous crazyfile later.

I ordered extra anchors to start working with TDoA and more crazyflies.

Starting to be really fun.

Regards.

Vincent.

Hello Arnaud.

I found the source of the problem as I still have crazyfiles bouncing on the walls.
It's radio related. I just check using rostopic echo /crazyflie/log_ranges and when moving the crazyflie by hand in the scene, depending on distance and relative antenna orientation I have measurement not updating ( it keeps the last received distance ). It also seems that one of my anchor sometimes is not received ( battery problems? ) . And as you seems to keep the last distance even if the fly is moving, It seems to cause increasing errors...

Have you tested deck with more omnidirectional antennas?

I'll see if It works better if Increase the output power of both node and deck.
I also see that you use the same frequency for all nodes. As we use 6 nodes and the dwm1000 supports 6 frequencies, why not use radio diversity?

U keep you posted.

Regards.

Vincent.

Hi Vincent,

Please keep us updated of your progress for the radio power. This is something we have not tested yet and I am very interested by the results.

For the channel, in theory low frequency should yield in longer range, so maybe some channel will be better. Though I do not see the point of using more than one channel for increasing the range, could be useful to increase the bandwidth of the system but I cannot see for the range.

/Arnaud

Hi,

We just discovered a stupid bug that might have caused much of the wall banging: viewtopic.php?f=17&t=2279.

I also inaugurated a new anouncement channel in the forum where I will post important bug fix and changes in the LPS.

/Arnaud