I’m currently working on getting a mocap setup (optitrack) working with the crazyflie 2.0 flashed with px4.
I’m not sure why but when I connect my crazyflie 2 (CF2) to mavros via cfbridge, I get a lot of reoccurring warnings for parameter requests timing out and params missing. I am still able to change the flight mode and arm/disarm with some degree of success, but I cannot seem to get the mocap data (mavros/vision_pose/pose) to be recognized by mavros over wireless.
However, when I connect the CF2 via usb @ /dev/ttyACM0:921600, I have been able to successfully publish mocap data to /mavros/vision_pose/pose and see the pose data when subscribed to /mavros/local_position/pose. I also see mavros echo [lpe] vision position init .
Basically, when using CFBridge with the CrazyRadio PA, packets are lost occasionally. The data path is unreliable. I’m not sure where the reliability issue is. Is it UDP? Seems unlikely since the datagrams are not transmitted over a physical link. @dennisss probably knows, since he is the author of CFBridge.
My guess is that the CrazyRadio / NRF2 chip has reliability issues, and the mavlink protocol does not provide reliable transport either.
Everything works great over USB because it is a much more reliable communications link, with very high bandwidth.
Furthermore, I don’t think the mavlink module running on the crazyflie tries to transmit every topic over the NRF2 chip; rather, it has a different subset of topics that it will transmit for each communications link.
This is indeed a bummer. The communication is probably unreliable in both directions, meaning some of the mocap data is probably corrupted / lost before it even gets to the crazyflie.
Ahh, I had a feeling the radio might be the issue. Connecting over cfbridge to QGC or mavros always seems to yield a shaky connection with relatively frequent disconnection to the crazyflie. As a result, mavros reports 500+ params missing and QGC never fully loads the parameters.
