Coordinate System Information

Related components: Autopilot Inference, Cerebra Studio – Mission Planner.

The Origin One navigates in Cartesian space, which is a mathematical definition of space that is defined with a global origin and further divided into three orthogonal directions, i.e., X, Y and Z. The global origin is a virtual point in the real world defined by the values X=0, Y=0 and Z=0. With the global origin defined any object in this space has a position, i.e., some values in the directions of X, Y and Z, and it also has an orientation, i.e., some values for the object's rotation around X, Y and Z. However, since the Origin One is a ground vehicle we typically only need to define values for X, for Y and for the rotation around Z (called heading).

Global origin (set when initializing)

The global origin is set by the robot during the initialization process. Depending on whether the robot operates completely indoors or completely outdoors this global origin is set as follows:

• Indoor operations are defined by the Aruco marker at which the robot is booted. The Origin One is delivered with 3 markers all saved in the database of the robot. The Aruco marker with ID = 0 has been saved with X = 0, Y = 0 and heading = 0. Therefore, as long as you do not change these values of Aruco marker 0 in the database, then the real-world position of Aruco marker 0 is the global origin of the robot's navigation. Further, the X-axis of the global frame points to the right of the Aruco marker, while the Y-axis points to the back of the marker.
• Outdoor operations are defined by RTK-GNSS fixes with values for Latitude, Longitude and Altitude, although Altitude can be discarded for the 2D case. When the Origin One is booted outdoors, then the real-world position at which it is booted is defined as the global origin of the robot's navigation. Further, the X-axis of the global frame is defined equal to Eastern direction, while the Y-axis is defined equal to the Northern direction.

Coordinate System

In case the Origin One only operates indoors, then the position of Aruco marker ID=0 defines the global origin. And thus as long as the real-world position of the marker is not changed, and nor are the values of its pose in the robot's database, the global origin shall always represent the same real-world position. However, when the robot is operating outdoors the global origin is defined by the first Latitude and Longitude measured. Therefore, the global origin may differ between operations as the robot might not be starting from the same outdoor position. To be able to retrieve the real-world position of the global origin the robot will publish the Latitude and Longitude of the global origin on the topic /origin/autopilot/coord_info (which stands for Coordinate System Information).

ros2 topic echo /origin/autopilot/coord_system

The topic will show the Latitude and Longitude of the global frame, as soon as these values have been defined. For the outdoor case this is the moment that the first RTK-GNSS measurements are received. Therefore, when booted outdoors a service call is made after receiving the first RTK-GNSS fix to set the Coordinate System Information with the Latitude and Longitude of this first fix. For the indoor case no RTK-GNSS fix will ever be received. However, the Origin One MUST have a Coordinate System Information that has been published on /origin/autopilot/coord_info, as that defines the global origin, otherwise it will not be allowed to localize and navigate. To solve this issue the robot has a coordinate system stored in its local database with some latitude, longitude and altitude. Therefore, when booted indoors a service call is made after detecting the Aruco marker to set the Coordinate System Information with the Latitude and Longitude that were stored in the database of the robot.

Info

Upon delivery the coordinate system stored in the database of the robot is set to a Latitude and Longitude that corresponds to the Avular office. You may change these stored values by using the following service call:

ros2 service call /autopilot/information_manager/set_stored_robot_coord_info knowledge_base_msgs/srv/SetRobotCoordInfo "{\"coord_info\": {\"type\": 1, \"map_name\": \"\", \"latitude\": 51.4532247, \"longitude\": 5.4484141, \"altitude\": 64.14, \"zone\": -1, \"north\": true, \"x_offset\": 0.0, \"y_offset\": 0.0, \"z_offset\": 0.0}}"

Where you change the values for the Latitude and Longitude with the ones you desire.

Note

When your robot only operates indoors than these stored Latitude and Longitude do not really matter, as the robot will never receive any RTK-GNSS fix and its global origin is defined by the real-world position at which Aruco marker 0 is located.

Warning

The Origin One will not understand that the real-world position of the global orgiin was changed when you re-position Aruco marker ID=0. For the robot this is simply the global origin, always. Therefore, if you want to re-position Aruco marker ID=0, and put it in a different environment, then first remove all maps, paths, polygons and waypoints of the robot's database.

Navigation data

Over time the robot may use different (Latitude and Longitude) values for its coord_system, i.e., the global origin of the robot user for navigation. And each time you create a new data object in Cerebra Studio, such as a map, polygon, path or waypoint, it will be stored with respect to Latitude and Longitude of the coord_system that the robot is using at that moment, i.e., that is being published for that operation. So over time the different data objects in the database will have different values for their coord_system. The pose with which each of those data objects is stored thus represents the shift in X and Y with respect to the values of the global frame that is linked to that specific data object in the database.

The picture below aims to illustrate this idea of different coordinate systems per data objects. Herein, the polygon and path have been defined in an earlier operations of the robot and thus with respect to some earlier coordinate system, i.e., CS-1, while the waypoint was defined in the current operations in which the robot booted not at CS-1 but at some other real-world position referred to as CS0.

The benefit for storing each object pose in the database wrt Coordinate System Information, i.e., Latitude and Longitude, of that specific operation is that although a waypoint (or path or polygon) has been defined in a prior operation (with a different Coordinate System Information), it will still remain the same real-world (outdoor) position in any of the new operation. The one thing that the Autopilot Inference must do is to re-compute the X and Y of a waypoint from the prior Coordinate System Information into the Coordinate System Information that is currently being used by the robot. Such a built-in function exists in the Autopilot Inference.

Note

Since the X-axis is always pointing East and the Y-axis is always pointing North in any new definition of the Coordinate System Information, i.e., the global origin, we only need to adjust the X and Y values of a 2D pose and not its heading, as the orientation of the global frame shall always point in the same direction.

However, this only applies when the global origin shifts within a distance of max 5 km. Otherwise the fact that the Earth is round will do have some effect on the orientation of the global frame.

As this transformation is done for every 2D pose, i.e., a point (X,Y), in the database of the robot, we have that all data objects are correctly transformed to the (new) Coordinate System Information at which the robot is booted: Maps, Polygons, Paths and Waypoints.

Warning

In case you are operating indoors and you have changed the values of the stored Coordinate System Information of the robot's knowledge base, then your stored Maps, Polygons, Paths and Waypoints will also have been shifted (virtually). Therefore, if you did not change the real-world position of Aruco marker ID=0 accordingly, then those Maps, Polygons, Paths and Waypoints will not reflect the same (prior) real-world position anymore.

Best is to delete all Maps, Polygons, Paths and Waypoints when you change the coordinate system stored in the robot.