Revision history [back]

Wrt the 3 transform trees, it's worth spending some time designing and carefully naming the coordinate frames that you'll be using in your robot. Once you have a plan, you can make sure that each transformation is provided by some node. roswtf can be helpful to find problems.

I'm making assumptions based on your use case, but I would suggest something like the following. Caveat: this is may not work for your use case or the code you're using.

• map
• base_link. map -> base_link should be provided the marker detection code. Note that the marker detector is actually computing camera_optical -> marker_frame, but using the TF2 code to calculate and publish map -> base_link instead. The origin of base_link should be in the center of the drone at the lowest point, so that when the drone is on the ground the the drone pose z is 0. In the body frame, +x should be forward along the drone, +y should be left (port), +z should be up. See REP 103 if this is confusing.
• camera_link. base_link -> camera_link should be specified in the URDF (assuming it's static) and published by robot_state_publisher. The assumption that most people make is that cameras face forward (+x along the body). If the camera is facing down, apply the pitch rotation here.
• camera_optical. camera_link -> camera_optical should also be specified in the URDF. See rep 103 for the rotation.
• marker_frame. map -> marker_frame should be provided by whatever mapping code you're using. N.B. if you're using OpenCV and ArUco markers you may need 2 frames per marker: one that follows rep 103, and one that is rotated into the position that OpenCV expects.

I assume that fcu is another name for base_link? I'm also guessing that frd is a different coordinate frame in mavros -- maybe NED vs ENU? I'm not entirely sure what local_origin is.

I hope this helps.