Modified 2019-10-06 by AmaurX
The details of the first layer of the localization system, the ros wrapper.
Knowing what the processed input to the localization system is. ()[#localization-input-processing].
Knowing the role of the ROS listener (layer 1) of the localization system does.
Modified 2019-10-06 by AmaurX
As stated in Part F - Localization System - Software explanation, the localization graph optimizer works in layers:
This part of the docs focuses on layer 1, the ROS listener.
This layer has the rode node. It can work either online or offline:
/pose_acquisition/poses
and /pose_acquisition/odometry
, which respectively receive transforms from apriltag detection and odometry transformsThe received stamped transforms all need to be filtered and formatted the same way and have consistent agent names between them (see example below).
Notation: This layer receives stamped transforms and outputs formatted transforms to the resampler.
Modified 2019-10-06 by AmaurX
Upon receiving a stamped transform from an Apriltag detection, we needs to filter the stamped transform’s following attributes:
header.frame_id
–> agent which detected the apriltagheader.tag_id
–> apriltag numberThe frame_id
will always be a duckiebot or a watchtower, for instance autobot01
or watchtower03
.
But the tag_id
will always be a number. We therefore need a list of apriltag attribution. For instance, the default attribution of apriltag 402 is autobot03
, but the one for apriltag 53 is a traffic sign.
There are three possible case for a apriltag message:
tag_id
is for instance 402tag_id
is not in the 4XXThe main issue is then that autobot03 is referred as 402 when seen, but as itself when it send a transform. So, thanks to the list of attribution, in the first case, we change the tag_id to autobot03
.
Modified 2019-10-06 by AmaurX
Upon receiving a odometry transform, we get the transform’s following attributes:
header.frame_id
header.child_frame_id
The two are the same, since an odometry transform is just a transform between the autobot at time t1 and the autobot at time t2.
Modified 2019-10-06 by AmaurX
Let’s formalize some frame definitions:
The autobot has three important frames to consider:
autobot_base
frame, located on the top red plate, center of the wheels, X forward, Y left and Z upward (in the driving direction). This is the frame that is considered for the graph.autobot_apriltag
frame, which is on top of the botautobot_camera
frame, which is centered in the lens, Z forward, Y down, X right. And the camera is mounted on a 10 degrees stand.
All three frames are attached by static transforms (meaning they don’t change relative poses to one another).The watchtower just has one frame, called watchtower_camera
. It is the one of the camera, described as the one of the autobot_camera
.
The rest of the apriltags have also one frame, called apriltag_base
.
Since we want to consider the autobot only in its autobot_base
frame, this means two things:
watchtower_camera
to autobot_apriltag
. They therefore need to be transferred to be watchtower_camera
to autobot_base
. The autobot_apriltag
to autobot_base
is a known transform that is applied to all such transforms. autobot_camera
to apriltag_base
, so we transform them to autobot_base
to apriltag_base
by using the know static transform autobot_base
to autobot_camera
. Note that in the first case, it is a right multiplication, and in the second a left multiplication (in SE3).Modified 2019-10-06 by AmaurX
Each odometry or apriltag stamped transform message comes with a timestamp. Since we want to track the movement in time of each autobot, those are very important to keep and transmit with the transform.
For things that don’t move, e.g. the watchtowers and the apriltags that are not on autobots, we don’t need to keep the timestamp. This only happens when the transform is from a watchtower_camera
to an apriltag_base
(which is not on an autobot).
Modified 2019-10-06 by AmaurX
The ROS listener makes sure to transmit formatted transforms with the right frame ids (parent and child), to the right frames of reference (autobot_base
for the autobots), with the right time stamps.
At the end of the pipeline, it receives back optimized estimates of the trajectories of the autobots and of the positions of the watchtowers. It then publishes them and stores them.