ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Going off of the solution that @tmoore gave, i wanted to share the entire setup that i have which is to big to fit in a comment. FYI, the code changes i made are most likely not the proper way of doing things, but the launch file configurations are good.

Here is a pastebin link to my launch file for Node 1

And another link to my launch file for Node 2

Im first trying to get this to work in a gazebo simulation before trying it on my actual robot. Theres a few things to note that i changed:

  • I changed the ar_sys source to instead publish a geometry_msgs/PoseWithCovarianceStamped instead of a geometry_msgs/Pose
  • I changed the ar_sys source to not broadcast the image frame (camera) -> marker transform, but instead lookup what the static transform is between the base_link and the camera frame on my robot and applied that static transform to the pose estimate that ar_sys gives, as @tmoore suggested in one of his recent comments. This way the ar_sys pose data was now being published relative to the base frame of the robot. So ar_sys does not publish any transform at all. You can reference @tmoore 's description for Node 2.
  • I also changed around the rotation that was made in the utils.cpp of ar_sys to report the pose so that if my robot moved further away, the x component of the pose msg would increase, rather then the Z component. (I know this is definetely not the proper way to go about the rotation of data, so feel free to correct me).

My robot's static transforms are defined like this (i tried using tf2, but i couldnt get the proper rotation of the camera's optical frame unless i used the original tf static publisher)

One thing i need to mention is that when lookup the static tf to apply to the ar_sys pose message, I only lookup base_link -> blackfly_mount_link , rather then blackfly_optical_link which has the rotations (in the attempt to proper conform to the ROS image standards because i couldnt figure out how to apply to rotation of the static transform lookup to the ar_sys poseMsg. So only the translation of the ar_sys pose message is now changed.

Here are a few pictures:

C:\fakepath\Screen Shot 2015-09-14 at 10.42.45 AM.png C:\fakepath\Screen Shot 2015-09-14 at 10.44.43 AM.png C:\fakepath\Screen Shot 2015-09-14 at 10.45.10 AM.png

Going off of the solution that @tmoore gave, i wanted to share the entire setup that i have which is to big to fit in a comment. FYI, the code changes i made are most likely not the proper way of doing things, but the launch file configurations are good.

Here is a pastebin link to my launch file for Node 1

And another link to my launch file for Node 2

Im first trying to get this to work in a gazebo simulation before trying it on my actual robot. Theres a few things to note that i changed:

  • I changed the ar_sys source to instead publish a geometry_msgs/PoseWithCovarianceStamped instead of a geometry_msgs/Pose
  • I changed the ar_sys source to not broadcast the image frame (camera) -> marker transform, but instead lookup what the static transform is between the base_link and the camera frame on my robot and applied that static transform to the pose estimate that ar_sys gives, as @tmoore suggested in one of his recent comments. This way the ar_sys pose data was now being published relative to the base frame of the robot. So ar_sys does not publish any transform at all. You can reference @tmoore 's description for Node 2.
  • I also changed around the rotation that was made in the utils.cpp of ar_sys to report the pose so that if my robot moved further away, the x component of the pose msg would increase, rather then the Z component. (I know this is definetely not the proper way to go about the rotation of data, so feel free to correct me).

My robot's static transforms are defined like this (i tried using tf2, but i couldnt get the proper rotation of the camera's optical frame unless i used the original tf static publisher)

One thing i need to mention is that when lookup the static tf to apply to the ar_sys pose message, I only lookup base_link -> blackfly_mount_link , rather then blackfly_optical_link which has the rotations (in the attempt to proper conform to the ROS image standards because i couldnt figure out how to apply to rotation of the static transform lookup to the ar_sys poseMsg. So only the translation of the ar_sys pose message is now changed.

Here are a few pictures:

C:\fakepath\Screen Shot 2015-09-14 at 10.42.45 AM.png Rviz

C:\fakepath\Screen Shot 2015-09-14 at 10.44.43 AM.png ar_sys image

C:\fakepath\Screen Shot 2015-09-14 at 10.45.10 AM.png

tf_tree

Going off of the solution that @tmoore gave, i wanted to share the entire setup that i have which is to big to fit in a comment. FYI, the code changes i made are most likely not the proper way of doing things, but the launch file configurations are good.

Here is a pastebin link to my launch file for Node 1

And another link to my launch file for Node 2

Im first trying to get this to work in a gazebo simulation before trying it on my actual robot. Theres a few things to note that i changed:

  • I changed the ar_sys source to instead publish a geometry_msgs/PoseWithCovarianceStamped instead of a geometry_msgs/Pose
  • I changed the ar_sys source to not broadcast the image frame (camera) -> marker transform, but instead lookup what the static transform is between the base_link and the camera frame on my robot and applied that static transform to the pose estimate that ar_sys gives, as @tmoore suggested in one of his recent comments. This way the ar_sys pose data was now being published relative to the base frame of the robot. So ar_sys does not publish any transform at all. You can reference @tmoore 's description for Node 2.
  • I also changed around the rotation that was made in the utils.cpp of ar_sys to report the pose so that if my robot moved further away, the x component of the pose msg would increase, rather then the Z component. (I know this is definetely not the proper way to go about the rotation of data, so feel free to correct me).

My robot's static transforms are defined like this (i tried using tf2, but i couldnt get the proper rotation of the camera's optical frame unless i used the original tf static publisher)

One thing i need to mention is that when lookup the static tf EDIT:

I no longer have a blackfly_mount_link -> blackfly_optical_link static transform as i instead created a static transform map -> board_marker with only a rotation, to put the ar_sys pose data in the orientation of the robot's base frame.

I only changed the second ekf launch file which you can view here

And you can view the code I use to apply to base_link->blackfly_mount_link transform to the ar_sys pose message, I only lookup base_link -> blackfly_mount_link , rather then blackfly_optical_link which has the rotations (in the attempt to proper conform to the ROS image standards because i couldnt figure out how to apply to rotation of the static transform lookup to the ar_sys poseMsg. So only the translation of the ar_sys pose message is now changed.

data [here] (https://github.com/chicagoedt/rmc_software/blob/master/ar_sys/src/multi_boards.cpp#L183) .

I deleted the old pictures as they where incorrect. Here are a few pictures:

Rviz

ar_sys image

tf_tree

some new ones

image description image description image description

Going off of the solution that @tmoore gave, i wanted to share the entire setup that i have which is to big to fit in a comment. FYI, the code changes i made are most likely not the proper way of doing things, but the launch file configurations are good.

Here is a pastebin link to my launch file for Node 1

And another link to my launch file for Node 2

Im first trying to get this to work in a gazebo simulation before trying it on my actual robot. Theres a few things to note that i changed:

  • I changed the ar_sys source to instead publish a geometry_msgs/PoseWithCovarianceStamped instead of a geometry_msgs/Pose
  • I changed the ar_sys source to not broadcast the image frame (camera) -> marker transform, but instead lookup what the static transform is between the base_link and the camera frame on my robot and applied that static transform to the pose estimate that ar_sys gives, as @tmoore suggested in one of his recent comments. This way the ar_sys pose data was now being published relative to the base frame of the robot. So ar_sys does not publish any transform at all. You can reference @tmoore 's description for Node 2.

EDIT:

My robot's static transforms are defined like this (i tried using tf2, but i couldnt get the proper rotation of the camera's optical frame unless i used the original tf static publisher)

EDIT:

I no longer have a blackfly_mount_link -> blackfly_optical_link static transform as i instead created a static transform map -> board_marker with only a rotation, to put the ar_sys pose data in the orientation of the robot's base frame.

I only changed the second ekf launch file which you can view here

And you can view the code I use to apply to base_link->blackfly_mount_link transform to the ar_sys pose data [here] (https://github.com/chicagoedt/rmc_software/blob/master/ar_sys/src/multi_boards.cpp#L183) here .

I deleted the old pictures as they where incorrect. Here are some new ones

image description image description image description

Rviz

Gazebo

TF Tree

Going off of the solution that @tmoore gave, i wanted to share the entire setup that i have which is to big to fit in a comment. FYI, the code changes i made are most likely not the proper way of doing things, but the launch file configurations are good.

Here is a pastebin link to my launch file for Node 1

And another link to my launch file for Node 2

Im first trying to get this to work in a gazebo simulation before trying it on my actual robot. Theres a few things to note that i changed:

  • I changed the ar_sys source to instead publish a geometry_msgs/PoseWithCovarianceStamped instead of a geometry_msgs/Pose
  • I changed the ar_sys source to not broadcast the image frame (camera) -> marker transform, but instead lookup what the static transform is between the base_link and the camera frame on my robot and applied that static transform to the pose estimate that ar_sys gives, as @tmoore suggested in one of his recent comments. This way the ar_sys pose data was now being published relative to the base frame of the robot. So ar_sys does not publish any transform at all. You can reference @tmoore 's description for Node 2.

EDIT:

My robot's static transforms are defined like this (i tried using tf2, but i couldnt get the proper rotation of the camera's optical frame unless i used the original tf static publisher)

I no longer have a blackfly_mount_link -> blackfly_optical_link static transform as i instead created a static transform map -> board_marker with only a rotation, to put the ar_sys pose data in the orientation of the robot's base frame.

I only changed the second ekf launch file which you can view here

And you can view the code I use to apply to base_link->blackfly_mount_link transform to the ar_sys pose data here .

I deleted the old pictures as they where incorrect. Here are some new ones

Rviz

Gazebo

TF Tree

EDIT 2:

Now that I have the 2 EKF nodes running and all my tf configurations correct, my "map" frame is the fused data of EKF1 (only imu) output and the ar_sys poseWithCovarianceStamped. If i view the data in rviz with Fixed Frame set to "map", I do see the odometry move mostly correct (If need be I can explain why I say mostly, as it is something to do with the code modifications i made to ar_sys): if I move the robot in the +x direction, my EKF2 output is almost dead on, and the orientation is as well (i only have orientation data coming from the imu and not ar_sys). However, if I view the data in rviz with the Fixed Frame set to "odom", I do not see any translational motion, but only orientation data changing (the tail of the vector always remains at the origin). Ive been trying to figure out this for a while now, but this is where I am stuck on as I need translational motion in the odom frame as well.