stateEstimate logging varies with a static CF

[a240160572]

Hey, I am working on my cf with Vicon motion capture system. However, there is some problem with running even HelloWorld.

The cf is capable of realizing the test flight with flowdeck in https://www.bitcraze.io/documentation/tutorials/getting-started-with-stem-drone-bundle/. Therefore, I would say that the cf and crazyradio are functioning. But together with crazyswarm and Vicon, the performance is wired. The cf drifts during take-off. Here is a logging from Vicon when I run HelloWorld:

During my troubleshooting, I noticed that the stateEstimate log varies even when the cf is standing still on floor, as the plot below:

I do not know if the wired state estimation is related to my problem. But it is appreciated if someone can help with an explanation.

[jpreiss]

probably some communication issue, check the radio channels and addresses in your crazyflies.yaml.

[a240160572]

probably some communication issue, check the radio channels and addresses in your crazyflies.yaml.

Here is my CF id: 'radio://0/80/2M/E7E7E7E703',
and my crazyflies.yaml setting:
`crazyflies:

• channel: 80
  id: 3
  initialPosition: [0, 0, 0.0]
  type: default`

I think these two are aligned, right?

[whoenig]

Perhaps you forgot to upgrade the firmware of your Crazyradio. The default firmware does not support broadcasts.

[a240160572]

Perhaps you forgot to upgrade the firmware of your Crazyradio. The default firmware does not support broadcasts.

The Crazyradio is with the latest release 0.53.
Here is my result from lsusb -d 1915:7777 -v | grep bcdDevice:
can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable bcdDevice 0.53.

The warning seems does not influence the communication given I am able to connect to the cf with cfclient or execute HelloWorld remotely.

[whoenig]

a correctly updated firmware shows version 0.99. Your version does not support broadcasts.

…

On Wed, Aug 31, 2022, 14:14 Lin Zuo ***@***.***> wrote: Perhaps you forgot to upgrade the firmware of your Crazyradio. The default firmware does not support broadcasts. The Crazyradio is with the latest release 0.53. Here is my result from lsusb -d 1915:7777 -v | grep bcdDevice: can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable bcdDevice 0.53. The warning seems does not influence the communication given I am able to connect to the cf with cfclient or execute HelloWorld remotely. — Reply to this email directly, view it on GitHub <#681 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3SIPK53G3KX36SPJIYARLV35EDRANCNFSM6AAAAAAQAWX4JQ> . You are receiving this because you commented.Message ID: ***@***.***>

[a240160572]

When I ran HelloWorld (or other file, like figure8) and logged stateEstimate and ctrltarget, the crazyflie took off and drift/crashed.

The stateEstimate is always like:

while all ctrltarget stays at 0.

I tested the logging with some manual movement and it did work

I don't know if this warning matters:
/home/lin/crazyswarm/ros_ws/src/crazyswarm/scripts/pycrazyswarm/crazyflie.py:590: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. cfg = yaml.load(crazyflies_yaml)

[whoenig]

The warning doesn't matter.

Do you run the Crazyswarm in both experiments (flying vs. manual movements)? Also, did you remove the flow deck for your experiments with vicon? Which object tracking mode are you using?

[a240160572]

1. Logged both via ros, one with python file and one without.
2. Yes, the flow deck is removed.
3. I used MotionCapture and the crazyflie has its unique 4-marker arrangement.
4. Some addition info in launchfile: estimator: 2 # 1: complementary, 2: kalman and controller: 2 # 1: PID, 2: mellinger

[whoenig]

Some people have more luck with the PID controller. Also, check if it helps to set the "https://github.com/USC-ACTLab/crazyswarm/blob/master/ros_ws/src/crazyswarm/launch/hover_swarm.launch#L36" to True (which would indicate that there are axis flips in Vicon Tracker).

[a240160572]

Hey, I tried both suggestions and here is the result:

1. PID:

Log from crazyflie, the same as before

Log from Vicon, you can see the drifting on Y axis is insane

2. send_position_only: True

Log from crazyflie, at least it is no longer static. But both plots I align the epoch to 1662035960 till 1662035961.5, the stateEstimate seems to have some lag.

In addition, the log from crazyswarm is stopped early with error: [ INFO] [1662037014.773707201]: [cf3] Takeoff terminate called after throwing an instance of 'std::runtime_error' what(): Unknown rigid body!

Log from Vicon, matches the real flight

Full track of the flight from Vicon

In addition, even though the cf is drifting, ctrltarget does not respond to that and correct the motion.

[a240160572]

Dear @jpreiss and @whoenig, sorry for disturbing you.

Is there a way I can have access to the data which is received by cf from vicon?
I was reading the vicon data via viconbridge package, and I would like to also inspect it from the cf side. Thank you.

[a240160572]

Yes. Unfortunately, we do not have the SD card deck yet.

[whoenig]

That's a neat test. I am not sure what delay we should expect here. The logging messages are buffered on-board, so if the buffer is always full, it will take a while before you get the latest information. You could try reducing the frequency (to make the buffer less full). I also assume you only connect to a single CF in this case? Otherwise the bandwidth limitations create latency also.

Note that logging messages also contain an on-board timestamp (in milliseconds). So one could try to find the offset between the PC and on-board clock and then compare the values without delay in postprocessing.

[a240160572]

Yes, only one CF.
I tested with only one logging parameter locSrv.x with 10Hz. The same latency is observed as logging 12 parameters with 10Hz.
If we assume the misalignment is from the onboard clock/transmission latency and all data should be synchronized onboard, then what could be the reason for the failed HelloWorld test?

Here is the flight of my HelloWorld test.
https://drive.google.com/file/d/13Cbl62bNR2gjQ7h8gtKHeX7nxPBWX0jt/view?usp=sharing
You can notice the serious drift and at the end, it left the detection area of Vicon (marked in blue on the floor) and landed on the safety net.

Thank you so much for all your help!

[whoenig]

In the video it really looks like the state estimator is not working properly - this sort of flight would also happen if you fly without any motion capture, just relying on on-board data. Could you look at the logging variables "stateEstimate.{x,y,z}", rather than "locSrv.{x,y,z}"?
Also, I assume you build the Crazyswarm with the Release flag? (https://github.com/USC-ACTLab/crazyswarm/blob/master/build.sh#L27).

[a240160572]

Thank you for the reply! I tested with a manual 3-axis movement. The dot-line is the log from viconbridge package, while the star-line is the log from locSrv.x/y/z.

It is evident that there is a delay (about 1.5-2 seconds) with the data set. Any idea what the cause would be?

The delay remains with or without set send_position_only to True. When send_position_only: False, the log term ext_pos.X/Y/Z are always 0. The delay also remains with a new CF and a new Crazyradio.

The stateEstimate.{x,y,z} is the same as locSrv.{x,y,z} in this plot.
The build.sh is also as default, catkin_make -DCMAKE_BUILD_TYPE=RelWithDebInfo.