PROTON Robots

Main functionalities

The main purpose of the ROS module is enabling the robots to navigate autonomously in and between outdoor and indoor environments without interruption. The sensors and switching software technology will have been developed and tested. The module will be ready as a ROS package to be integrated in our robots, but will also be capable of servicing other automated vehicle platforms. The software solution consists of ROS nodes that can be integrated in each robot ROS framework. The general purpose ROS node is called trinity_switch_position_system. The PROTON Robots module is especially focused and best intended for alternating scenarios (e.g. indoor/outdoor) and suited for environments in which the sensor sources need to change (e.g. GNSS gets disabled when entering an indoor environment), and enables a modular transparency for the robot layer software towards the positioning techniques and sensor technologies being used at each moment.

Technical specifications

-ARCHITECTURE- The architecture of the solution encompasses 2 potentially distinct pipelines, accounting for different localization systems different robots utilize: ● Node called position_selector is for pipelines where values from sensors are filtered onboard beforehand as an embedded solution, where the node’s responsibility is choosing the best sensor for outputting to the rest of the software based on accuracy ● Node called sanity_checkers is for pipelines where the data from the sensors are fused, and the node’s responsibility is informing the sensor fusion system of unreliability of a sensor via error messages, in turn reducing the weight of trust in said sensor during the calculation of localization estimation One important part is determining when the GNSS signal received is corrupted or of low quality so that relevant actions can be taken for switching to a more reliable source of localization. For that purpose, a ROS node called sanity_checkers was developed. The main purpose of this ROS node is determining whether the odometry data we receive from GNSS is “sane” before starting operation and also during the operation, as the reliability of the signal can change while the robot is moving during operation. sanity_checkers has 3 core functionalities: 1. Upon receiving a ROS service request “is_there_utm” (usually from a state machine), the node will check whether georeferenced localization is available via a coordinate frame lookup. If this check is successful, this means that the GNSS receiver and its drivers are working properly, is receiving NTRIP (Networked Transport of RTCM via Internet Protocol) messages from RTK base station and the robot is localized according to UTM (Universal Transverse Mercator) map projection. On success, a ROS service response is sent, allowing robot operation to commence. After the ROS service response is sent, the next 2 recurring checks are also triggered to start. 2. There’s also a need for parsing through the self-diagnostics that are generated by the GNSS drivers that give information about the quality of the signal received. What’s parsed are 1) Whether if the fix from the driver is in error state, giving information regarding the usefulness of the data received and 2) the number of satellites visible and used for localization, which can be compared to a configurable number, that’s the minimum number of visible satellites considered to be required for proper operation. If any of these conditions are triggered within the function, a relevant error code will be published that’s used to trigger the switching system. A decision was made to use the topic “/diagnostics” and the ROS diagnostics interface in order to be able to support as many different GNSS vendors as possible. 3. This function is for comparing the velocity information we derive from the GNSS based localization algorithm to the kinematic capabilities the robot has. Comparing the distances the robot is assumed by the GNSS source to be moving within the geolocalized UTM frame during a set time to the actual speed the robot is capable of moving at, it can be determined whether there was a significant “jump” between the coordinate frames, concluding that the GNSS data received is unreliable. If this condition is triggered, again a relevant error code will be published, triggering the switching system.

Inputs and outputs

-ROS parameters- Here are the configurable parameters of the module: ● robot_tf – Coordinate frame of the robot – default value is “base_link” as per ROS guidelines ● geolocation_tf – Coordinate frame for georeferencing – default value is “utm” as per ROS guidelines ● gps_diag_name – Name of the GPS fix node inside diagnostics messages – default value is “ublox: fix” as per ublox receiver this node was tested with ● visible_satellite_key – Key of the value in diagnostics messages that corresponds to the value of visible satellites currently utilised – default value is “# SVs used” as per ublox receiver this node was tested with ● distance_threshold – Related to the function number 3, this parameter decides how much travel distance per timer_period is kinematically unreasonable for the robot to have travelled ● timer_period – Again related to the function number 3, this parameter decides how often the distance travelled per GNSS localization is checked ● min_vis_sat_num – Related to function number 2, this parameter decides the minimum number of satellites visible to the GNSS receiver for the data to be considered reliable

Formats and standards

– Custom ROS message ErrorCode.msg – A custom ROS message was defined for better communication with the other parts of the system like the state machine and the switching system. It holds 2 values and has some predefined error_codes that are relevant to the sanity checks performed: ● hardware_id – Integer – for determining the hardware that the error stems from. Predefined value included with the message definition: ○ GPS ● error_code – Integer – for determining the nature of the error code. Predefined values included with the message definition: ○ FRAME_JUMP ○ FIX_ERROR ○ LOW_VIS_SAT – Custom ROS message Accuracy.msg – The procedure for the embedded switching mechanism consists in a ‘funnelling’ selection of the best accuracy available in each sensor. The one providing the best accuracy at each moment is selected for providing its positioning (and eventually also the pose) to the robot. The robot therefore only ‘sees’ one position provider and does not have to care about the source. For the selection of the best accuracy, an extension of the standard ROS Navigation message has been developed. The resulted message has been called Accuracy.msg, with following information: ● nav_msgs/Odometry_odo ● uint32 accuracy The accuracy signal is an integer stating the current accuracy of each sensor (expressed in centimeters). With this information, the switching mechanism takes the decision of using one or other positioning information from the sensors.

Owners (organizations)

10Lines

info@10lines.eu

+37253435265

Zenialabs Automation Intelligence
info@zenialabs.com
+34656768586

Training material

undefined

Owner (organization)

undefined

Documents

Trainings

To learn more about the solution, click on the link below to access the training on the Moodle platform
Precise positioning in alternating environments for autonomous railway inspection and parking lot striping robots