echo /pose issue

[AlEXANDER9901]

Hello, I came across a similar issue in this forum, but since the content of the question is different, I started a new discussion thread. We are currently using the OptiTrack motion capture system, and we've resolved the motion capture tracking issue as per the instructions in #322. However, we've encountered a new problem. When I run 'ros2 launch crazyflie launch.py,' there are no errors, and when I run 'rviz2,' there are no issues either. But when I try 'ros2 topic echo pose,' nothing appears. When I checked 'ros2 topic list,' I found that 'cf10/pose' exists, but nothing appears when I use 'echo' (as shown in the picture). Any advice would be greatly appreciated.

[Eric-Ewing]

What exactly are you trying to see? if all you want are the poses from optitrack, you can ros2 topic echo poses. I see that you're logging to /pose at 50hz, so are you trying to look at the crazyflie's pose estimate?

I think you actually have a different issue though, which is that the crazyflie hasn't finished connecting. The last message from the server is Requesting memories..., there should be at least one more message along the lines of radiobroadcast://*/100/2M. Sometimes the crazyflie can take a while to finish this stage of connection. This is part of a larger issue going on with communication that can hang sometimes (see #265). I will typically reboot the crazyflie with ros2 run crazyflie chooser.py and it should work again once it reboots. You could also try unplugging your radio and plugging it back in or restarting the server, both of which might help.

[AlEXANDER9901]

And also, when I run the 'hello_world' example, there is a problem. It shows 'ESTKALMAN: state out of bounds, resetting,' and the drone flips over.

[Eric-Ewing]

1. 100hz motion capture shouldn't be giving a rate off warning. The warning means the motion capture data is being received at an unexpected rate (in this case, 100hz). What does your motion_capture.yaml file look like?
2. radiobroadcast://*/100/2M gets printed immediately after a CrazyflieROS object is created and is to identify the broadcast channel of the crazyflie. So it's both useful in that it prints the channel and in that it signifies the crazyflie has been connected.
3. There are other discussions on getting the hello_world to work when the crazyflie is flipping. Try to read those discussions and see if you have a similar issue. It's possible that trying to log pose at 50hz is overwhelming the crazyflie. When you log with the firmware_parameters, it requires communication from the firmware. If you want the pose data for something, you can either reduce the logging hz (e.g. 10hz), use a uSD deck to log to a uSD card and get the data later, or get the pose data from /poses or /tf, which does not require radio communication.

[AlEXANDER9901]

Thank you for your response.

1. This is how the motioncapture.yaml file looks. I tried changing the deadline from 50 to 120, but the error remains the same, only the update speed changes. I also attempted altering the camera framerate in Motive, yet the issue persisted.
   `/motion_capture_tracking:
   ros__parameters:
   type: "optitrack"
   hostname: "192.168.0.81"

   mode: "motionCapture" # one of motionCapture,libRigidBodyTracker

   topics:
   poses:
   qos:
   mode: "sensor"
   deadline: 100.0 # Hz

   marker_configurations:
   default: # for standard Crazyflie
   offset: [0.0, 0.0, 0.0]
   points:
   p0: [ 0.0, 0.0, 0.022] # top
   p1: [-0.042, 0.042, 0.0 ] # back left (M3)
   p2: [-0.042, -0.042, 0.0 ] # back right (M2)
   p3: [ 0.042, -0.042, 0.0 ] # front right (M1)
   default_single_marker:
   offset: [0.0, -0.01, -0.04]
   points:
   p0: [0.0177184,0.0139654,0.0557585]
   mocap_deck:
   offset: [0.0, 0.0, -0.01]
   points:
   p0: [0.03, 0.0, 0.0] # front
   p1: [0.00, -0.03, 0.0] # right
   p2: [-0.015, 0.0, 0.0] # back
   p3: [0.00, 0.03, 0.0] # left
   medium_frame:
   offset: [0.0, 0.0, -0.03]
   points:
   p0: [-0.00896228,-0.000716753,0.0716129]
   p1: [-0.0156318,0.0997402,0.0508162]
   p2: [0.0461693,-0.0881012,0.0380672]
   p3: [-0.0789959,-0.0269793,0.0461144]
   big_frame:
   offset: [0.0, 0.0, -0.06]
   points:
   p0: [0.0558163,-0.00196302,0.0945539]
   p1: [-0.0113941,0.00945842,0.0984811]
   p2: [-0.0306277,0.0514879,0.0520456]
   p3: [0.0535816,-0.0400775,0.0432799]

   dynamics_configurations:
   default:
   max_velocity: [2, 2, 3] # m/s
   max_angular_velocity: [20, 20, 10] # rad/s
   max_roll: 1.4 #rad
   max_pitch: 1.4 #rad
   max_fitness_score: 0.001

   `

2. Thanks to your assistance, I managed to establish the connection.

3. I just reviewed a similar discussion, and I plan to try it tomorrow. However, there's a part I'm having trouble understanding: 'When you log with the firmware_parameters, it requires communication from the firmware.' Could you provide more detailed insight into what this means? Does it imply the necessity of redoing a firmware update? I'm currently trying to decrease the Hz to see if it works. I'm also curious if the uSD deck is a separate component that needs to be installed. I'd be extremely grateful for your response; your help has been invaluable. Thank you so much!

[Eric-Ewing]

1. 🤷‍♂️ try not logging any firmware parameters and see if you get stable flight, if not you may have to figure out some underlying issue with motion capture, but we'll need more information to debug if it persists.
2. 👍
3. requires communication from the firmware wasn't great phrasing on my part, but I meant that it requires radio messages from the crazyflie back to the crazyflie server that contain the poses. Those parameters that are being logged are parameters onboard the crazyflie that are sent to the server at the requested frequency. If all you want is the pose data, you can grab that from /poses or /tf, which comes from your motion capture instead of logging the firmware_parameter version (which would be the onboard pose estimate of the motion capture data fused with the imu data). This cuts out a lot of a lot of radio messages.
   3.5: The uSD deck is a separate deck: https://www.bitcraze.io/products/micro-sd-card-deck/. If you need to know anything onboard the crazyflie in depth (e.g. pose estimates at >50hz or imu measurements), you'll need to use this as the radio simply can't support too high of a frequency of parameter logging messages. If you actually need the onboard parameters/variables you should get it, if you just need ground truth position, get it directly from your motion capture topics and not from the firmware_logging options.

[AlEXANDER9901]

Thank you! I solved all problems, and the Crazyflie didn't flip. Your advice was helpful, including setting the firmware logging to false.