Open jakeelkins opened 2 months ago
motion_capture: enabled
to false (this is named confusingly - it should say use_librigidbodytracker)pose
default topic if that's the case.Thanks for the reply @whoenig, I really appreciate it.
When I set motion_capture: enabled
to false in crazyflies.yaml (all other config the same as in original message), the motion capture node dies with the following output:
Any thoughts? When I commented out the pose default topic, the tracking is fine and should be good enough for our tests. I would still, however, like to use the Motive track, as our setup seems to work well.
I have not seen this particular issue before.
One problem with these exceptions is that you only get useful information in a debugger. You could recompile with debugging enabled (see https://imrclab.github.io/crazyswarm2/howto.html#debugging), and then run the motion capture node with a debugger attached (using a prefix, see https://github.com/IMRCLab/crazyswarm2/blob/d9064d9802e476b9216d42cad735c3ace5bd20cf/crazyflie/launch/launch.py#L127 for an example).
I added the debugger to the motion capture node and recompiled with debug enabled. I also commented out the default pose topic. When I start the server with debug:=true, the motion_capture node and server hang with the following outputs:
On Motive, this was still with streaming unlabeled markers on.
When I only streamed the rigid body points and run the server with debug:=true, the motion capture seems to work for a second, then fails to receive data:
When I run the server with debug:=false is off, the poses look fine on rviz2 (that is, looks the same as what I've defined on Motive), but the motion capture tracking node still prints that the pose isn't updated:
Thanks again!
Two days ago the problem was that the motion_capture_tracking node essentially crashed. When you run with the debugger, the node doesn't crash anymore? It should be sufficient to only debug that node and keep the server running normally.
Yes sir, I was having trouble reproducing the behavior last Friday, but today I can consistently reproduce the behavior when the node crashes. here's the xterm output, though I don't see much new information:
Let me know if there's anything else I can do to get more info. I might switch over to a vicon system in another lab for the data we need -- we're trying to flash a custom quadrotor controller onto the crazyflie for trajectory tracking control, so I think we do need the nice pose data.
Thanks again for the help!
Update: I switched over to a Vicon system with Tracker, defined a rigid body in Tracker, and set all the motion_capture.enabled
to false
in my config files. Updated my ROS distro to Iron. I still get the InvalidParameterValueException from rclcpp, and the motion capture node crashes. It seems to only happen when the motion capture is not enabled for any robot in the config.
Hey guys, apologies for the long issue.
My lab is using one crazyflie with a mocap deck and custom marker positioning with a crazyradio2, with Motive 2.2.0 to do the motion capture. I have bootloaded the latest firmware from the cfclient, which is labeled as 2024.02.
We have a Rigid Body asset defined in Motive (defined as "cf_model_new") on a host machine, streaming data to the Ubuntu system to run crazyswarm2. Motive is doing a great job of tracking the rigid body, so we want to simply use the data coming in from Motive directly, rather than use libRigidBodyTracker or something on the point cloud. The crazyflie is named "cf5" in crazyswarm2 config.
The summary of the issue is that two different poses are represented on the /tf topic and the /poses topic. This is seen in rviz2 here:
When unlabeled markers is turned off in Motive streaming, the /cf5 frame becomes static. When I turn it on again, it re-coincides with the /cf_model_new frame, though it is very shaky. We suspect this is the culprit of poor hello_world performance. The frame /cf_model_new looks great in rviz2.
How can we tell crazyswarm2 to use this data, instead of resolving the unlabeled point cloud? I have seen to set motion_capture/enabled to false in the config. However, when I do this, the motion_capture_tracking node dies due to an InvalidParameterException.
My current config files are below. Note that I use optitrack_closed_source due to the old Motive version (2.2.0).
motion_capture.yaml:
crazyflies.yaml:
Note that I also get low unicast and multicast warnings due to old firmware, though I have the latest from the cfclient. if there is a newer firmware that might be the culprit, any info on how to find that file is appreciated. Let me know if I need to add any other warnings, files, or Motive settings.
Thank you so much! Jake