watonomous.github.io
[ Technical Integration : Coordinate Systems ]
Created by [ Rowan Dempster], last modified by [ Charles Zhang] on Mar 31, 2021
WATonomous follows ROS's REP 103 and 105 for coordinate frame naming and conventions: https://ros.org/reps/rep-0103.html, https://ros.org/reps/rep-0105.html
Why do we care about frames? Read the documentation on TF. The word "frame" is short for frame of reference and is slightly synonymous to coordinate system in this context, but they are not interchangeable, we will see why.
This document seeks to well define all the frames that are in use.
Defining a frame means selecting a physical point to represent the origin of this frame, as well as the direction of the axis for position and orientation. We have to be very careful with how position and orientation are defined for a particular frame. It has come to my attention that within a frame, the positions and orientation do not use the same "coordinate system", that is, the values representing position and orientation within a frame are with respect to different sets of axes. We also define the [colloquial] names, and TF frame names (the TF frame name is normally something unintuitive but maybe they should be the same?).
Understanding Orientation
Orientation is represented using quaternions or Euler angles. Euler angles are more intuitive to understand but are limited to the phenomenon of gimble lock. Euler angles represent the 3D orientation of an object using a combination of 3 rotations about different axes. This page provides a really good overview of Euler angles.
[Understanding]
Recall that a pose is a position and an orientation.
Here's a quick crash course for understanding how a frame may have separate sets of axes for position and orientation, and some explanation of common terminology. Firstly, all coordinate systems should be right handed coordinate systems. You should know what this is from high school physics. Implementation of non right handed coordinate systems will make things confusing for us.
The most exemplar case is how the novatel driver publishes pose. Recall that a pose is composed of a position and orientation. Here's a quick crash course on how the novatel driver publishes pose. The following figures are birds eye view of a coordinate system, so we can only see 2 axis, really.
The position of a point (default with no hacks) with respect to its coordinate system is really easy to understand. The x value is Easting. The y value is Northing. The Z value is elevation which we don't care about. The origin is some arbitrary point on the Earth within our UTM Zone.
[
{.confluence-embedded-image
.confluence-thumbnail height=”250”}]{.confluence-embedded-file-wrapper
.confluence-embedded-manual-size}
Figure 1: NovAtel Position Coordinate System
Understanding orientation is a little more complicated. Orientation is typically represented as a quaternion (4-tuple) which can be mapped to Euler angles (3-tuple), or roll-pitch-yaw (3-tuple). Euler angles describe the orientation of a rigid body with respect to some fixed coordinate system. It's best to talk about Euler angles because it's much easier to understand the values. In Euler form, an orientation of a rigid body with respect to some fixed coordinate system can be defined by 3 angles, pitch, roll and yaw. See the Figure below. Pay attention to the direction that the arrows curl. Wrap your right hand, with your thumb pointing in the positive direction of an axis. The curl of your fingers correspond to the positive angle direction.
[
{.confluence-embedded-image
.confluence-thumbnail height=”250”}]{.confluence-embedded-file-wrapper
.confluence-embedded-manual-size}
Figure 2: Aircraft Principle Axis
Frame Summary
The table below summarizes the proposed frames. The [frame]{.inline-comment-marker data-ref=”760e91dc-c46f-41aa-b096-d90fa6c4569e”} names are subject to change, but they should be intuitive and strongly correlate with the colloquial name.
Naming conventions align with REP 105 https://ros.org/reps/rep-0105.html. Coordinate systems align with https://ros.org/reps/rep-0103.html.
+------+---------+----------------+-----------------+-----------------+
| Coll | Frame | Frame Origin | Position | Orientation |
| oqui | Name | | Coordinate | Coordinate |
| al | | | System | System |
| Name | | | | |
+======+=========+================+=================+=================+
| UTM | map | (0, 0) | [East North Up | Yaw increases |
| | | Northing, | (ENU) | counter-clockwi |
| | | Easting | Convention](htt | se. |
| | | coordinate of | ps://en.wikiped | East is zero. |
| | | the current | ia.org/wiki/Geo | |
| | | UTM zone. We | detic_datum#Loc | |
| | | don\'t care | al_east.2C_nort | |
| | | about | h.2C_up_.28ENU. | |
| | | altitude. | 29_coordinates) | |
| | | | {.external-link | |
| | | \ | } | |
| | | | | |
| | | | - +x axis: | |
| | | | True East | |
| | | | - +y axis: | |
| | | | True North | |
| | | | - +z axis: | |
| | | | Upwards | |
+------+---------+----------------+-----------------+-----------------+
| Odom | [odom]{ | Depending on | [East North Up | Yaw increases |
| | .inline | zero\_start: | (ENU) | counter-clockwi |
| | -commen | | Convention](htt | se. |
| | t-marke | (0, 0) | ps://en.wikiped | East is zero. |
| | r | Northing, | ia.org/wiki/Geo | |
| | data-re | Easting | detic_datum#Loc | |
| | f="662f | coordinate of | al_east.2C_nort | |
| | 36d8-68 | the current | h.2C_up_.28ENU. | |
| | 37-4404 | UTM zone. We | 29_coordinates) | |
| | -9e91-d | don\'t care | {.external-link | |
| | abe17d7 | about | } | |
| | 3887"} | altitude. | | |
| | | | - +x axis: | |
| | | Startup | True East | |
| | | position of | - +y axis: | |
| | | the novatel | True North | |
| | | driver. We | - +z axis: | |
| | | don\'t care | Upwards | |
| | | about | | |
| | | altitude. | | |
+------+---------+----------------+-----------------+-----------------+
| IMU | [imu\_l | Roughly center | - +x | Same as IMU |
| | ink]{.i | of mass of | axis: Car | PCS. |
| | nline-c | NovAtel IMU. | heading | |
| | omment- | | - +y axis: | |
| | marker | | Left of car | |
| | data-re | | heading | |
| | f="8fab | | - +z axis: | |
| | a208-15 | | Upwards | |
| | 30-442a | | | |
| | -b62d-9 | | Assuming proper | |
| | a3e93a6 | | mounting. | |
| | 310a"} | | | |
+------+---------+----------------+-----------------+-----------------+
| Vehi | [base\_ | Approximate | - +x axis: | [Yaw is a |
| cle | link]{. | centre of mass | Car heading | steering angle |
| | inline- | of the | - [+y axis: | and ]{style="le |
| | comment | vehicle, | Left of car | tter-spacing: 0 |
| | -marker | located | heading]grow |
| | data-re | directly under | yle="letter-spa | c[ounter-clockw |
| | f="81e4 | the center | cing: 0.0px;"} | ise. |
| | 764c-fd | LIDAR, on the | - +z axis: | Positive turns |
| | 3a-4aff | ground. | Upwards | left, negative |
| | -a14d-0 | | | turns |
| | cede648 | | | right.]{style=" |
| | f762"} | | | letter-spacing: |
| | | | | 0.0px;"} |
| | | | | |
| | | | | [Zero yaw is |
| | | | | the positive x |
| | | | | axis]{style="le |
| | | | | tter-spacing: 0 |
| | | | | .0px;"} |
+------+---------+----------------+-----------------+-----------------+
| Left | camera\ | Centre of mass | - +x axis: | Zero yaw is the |
| Came | _left\_ | of left | Camera | positive x axis |
| ra | link | camera. | heading | and increases |
| | | | - +y axis: | counter-clockwi |
| | | | Left of | se |
| | | | camera | |
| | | | heading | |
| | | | - +z axis: | |
| | | | Upwards | |
+------+---------+----------------+-----------------+-----------------+
| Righ | camera\ | Centre of mass | - +x axis: | Zero yaw is the |
| t | _right\ | of right | Camera | positive x axis |
| Came | _link | camera. | heading | and increases |
| ra | | | - +y axis: | counter-clockwi |
| | | | Left of | se |
| | | | camera | |
| | | | heading | |
| | | | - +z axis: | |
| | | | Upwards | |
+------+---------+----------------+-----------------+-----------------+
| Lida | vlp3\_l | Centre of mass | - +x axis: | Zero yaw is the |
| r | ink | of central | Car heading | positive x axis |
| | | lidar. | - +y axis: | and increases |
| | | | Left of car | counter-clockwi |
| | | | heading | se |
| | | | - +z axis: | |
| | | | Upwards | |
| | | | | |
| | | | Assuming proper | |
| | | | mounting. | |
+------+---------+----------------+-----------------+-----------------+
| Fron | front\_ | {.content- | - +x axis: | Zero yaw is the |
| t | bumper\ | wrapper} | Car heading | positive x axis |
| Bump | _link\ | Frame centred | - +y axis: | and increases |
| er | (NOT | around the | Left of car | counter-clockwi |
| | IMPLEME | front bumper | heading | se |
| | NTED) | of the car. | - +z axis: | |
| | | | Upwards | |
+------+---------+----------------+-----------------+-----------------+
[
CARLA
CARLA follows the Unreal Engine coordinate system for all local-space coordinate (eg: vehicle frames). Ref: https://carla.readthedocs.io/en/latest/ref_sensors/.
[]{.aui-icon .aui-icon-small .aui-iconfont-info .confluence-information-macro-icon}
All the sensors use the UE coordinate system (x-forward, y-right, z-up), and return coordinates in local space. When using any visualization software, pay attention to its coordinate system. Many invert the Y-axis, so visualizing the sensor data directly may result in mirrored outputs.
This is a left-handed coordinate system. To turn this into a right handed coordinate system, negate the Y coordinate and invert the yaw angle. Note that the `carla_ros_bridge` does this for you already. But, if you ever retrieve coordinates directly through the Python API, you will need to perform these negation.
UTM
Position Coordinate System
Orientation Coordinate System
The vehicle's NovAtel system comprises 2 units: the PwrPak7, located on the driver seat armrest (July 2019) and the GNSS Antenna, mounted on the back of the roof rack (July 2019). The two systems together enable the car to be localized on the world map either under the form of Geographic (lat, long) or UTM, by simply changing a boolean in Clearpath's NovAtel ROS driver.
At WATOnomous, we use UTM coordinates: a flat earth representation of the world by defining small grid zones. Launching the ROS driver publishes the pose of the vehicle, which comprises of a quaternion orientation and 3-tuple position (northing, easting, elevation), to /navsat/odom. The ROS driver omits the grid zone! Waterloo and Michigan were both in the north hemisphere zone 17T, you can use a tool like geoplanner to lookup [UTM]{.inline-comment-marker data-ref=”4db2707d-aa16-4c29-b416-0b11f758b478”} locations by passing in either a Google query or lat-long pair. Each zone is represented like a 2D cartesian plan, and naturally the northing and easting values are relative to the zone and do not correspond to true north nor true east.
[]{.aui-icon .aui-icon-small .aui-iconfont-info .confluence-information-macro-icon}
[NOTE:] Coordinate transforms right now don't work as f[ar as I know (Simon)]{.inline-comment-marker data-ref=”8195bda6-14d4-491a-ba26-30945c45fa0d”}. Someone needs to revamp how coordinates are passed around. The rest of this document is outdated. After coordinates are revamped, please fix below.
UTM Zero Start
Path Planning is expecting data points in the UTM Offset coordinate system (odom_combined frame) which is defined as follows:
- (0,0) refers to the startup position of the novatel
- (0,1) is one meter NORTH, from the startup position
- (1,0) is one meter EAST, from the startup position
- (-1, 0) is one meter WEST, from the startup position
- etc...
IMU
[
{.confluence-embedded-image
height=”250”}]{.confluence-embedded-file-wrapper
.confluence-embedded-manual-size}
Lidar
[
{.confluence-embedded-image
.confluence-thumbnail height=”250”}]{.confluence-embedded-file-wrapper
.confluence-embedded-manual-size}
Novatel Driver
Novatel's drivers use a separate system for both local and vehicle coordinate frames.
Documentation:
- APN-037 Application Note on Vehicle to Body Rotations: https://hexagondownloads.blob.core.windows.net/public/Novatel/assets/Documents/Bulletins/apn037/apn037.pdf
- SPAN on OEM6 Firmware Reference Manual: https://hexagondownloads.blob.core.windows.net/public/Novatel/assets/Documents/Manuals/OM-20000144UM/OM-20000144UM.pdf
We have made modifications to the novatel_span_driver code to have it reflect the ROS coordinate frames.
\
Attachments:
imu.jpg (image/jpeg)
image2020-2-28_14-19-0.png
(image/png)
imu.jpg (image/jpeg)
image2020-2-28_15-30-56.png
(image/png)
Screen Shot
2020-02-28 at 4.08.52 PM.png
(image/png)
Screen Shot
2020-02-28 at 4.21.02 PM.png
(image/png)
Screen Shot
2020-02-28 at 4.28.13 PM.png
(image/png)
Screen Shot
2020-02-28 at 7.15.04 PM.png
(image/png)
Screen Shot
2020-02-28 at 7.14.50 PM.png
(image/png)
Screen Shot
2020-03-01 at 5.21.59 PM.png
(image/png)\
Comments:
+-----------------------------------------------------------------------+
| [] |
| |
| Changes needed: |
| |
| - base\_link and [vlp3\_link] |
| orientation does agree with ROS |
| spec: <https://www.ros.org/reps/rep-0103.html#axis-orientation> |
| - [camera\_\* frames are not |
| defined] |
| |
| {.smallfont align="left" style="color: #666666; width: 98%; margi |
| n-bottom: 10px;"} |
|  |
| Posted by r2dempst at Oct 23, 2020 22:10 |
| |
+-----------------------------------------------------------------------+
| [] |
| |
| Resolved in |
| MR [!93](https://git.uwaterloo.ca/WATonomous/wato_monorepo/-/merge_re |
| quests/93) |
| |
| {.smallfont align="left" style="color: #666666; width: 98%; margi |
| n-bottom: 10px;"} |
|  |
| Posted by cy9zhang at Feb 12, 2021 23:03 |
| |
+-----------------------------------------------------------------------+
Document generated by Confluence on Nov 28, 2021 22:41