The Sandbox: the AVSandbox knowledge hub

As progress is being made in the development of autonomous vehicles (AVs) and their functionalities, new problems constantly arise due to the uncertainty of the physical world with its varied unpredictability that can often cause an accident to occur. Due to this, an incredible amount of work is being done by OEMs with the development of virtual simulators to test the vehicle cognitive computing. With the approach of the perception module receiving computer generated scenes and mathematically modelled movement patterns for the different entities within the road, we can use simulator abstract visualisation tools to focus on the core capabilities of AVs. The management of AV systems is becoming more complex as the development of its technology progresses. We proposed an integrated development framework approach (which is currently being widely implemented) to enable co-simulation of ROS based AV systems using Autoware with our in-house developed simulation manager built around rFpro to configure, test, run and capture necessary results to validate ADAS features and autonomous vehicles’ behaviours [1].

Following my previous blog post on the introduction of Autoware [2], this second part focuses on ROS also known as a Robotic Operating System: What is it? What does it do? How is it integrated with Autoware?

As mentioned, Autoware is based on ROS [3] which is a component-based framework developed for robotics research. ROS is designed to enhance the modularity of robot applications and is suitable for distributed systems, while allowing for efficient development. Since autonomous vehicle development requires many software packages, ROS provides a strong foundation for Autoware’s development. It provides the services such as hardware abstraction, low-level device control, implementation of commonly used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers. Its overall software is abstracted as nodes and topics where nodes represent the individual component modules being usual standard programmes written in C++ and topics being mediator. Communication amongst nodes follows a publish/subscribe model. This model is a strong approach for modular development. In this model, nodes communicate by passing messages via a topic.

Figure 1. Publish & Subscribe model in ROS

ROS also includes an integrated visualisation tool which are:

•  RVIZ: The RVIZ viewer is useful for monitoring the status of tasks and
•  ROSBAG: ROSBAG, a data-driven simulation tool, is a set of tools for recording and playing back ROS topics.

It provides development environments for testing AV algorithms without hardware, thereby making development processes more efficient.

There are various ROS distributions [3] but in our own development purpose ROS melodic was the one required primarily for Ubuntu 18.04. There are few ways of installing ROS depending on the OS [4].

Figure 2. RVIZ visualization

After ROS installation comes Autoware’s which has proven to be more challenging than shown in [5, 6]. However, we recommend installing Autoware using a docker. Autoware linked with ROS provides multiple state-of-the-art algorithms for localisation, mapping, obstacle detection and identification using deep learning. It is a little bit complex and needs a deeper understanding of ROS packages.

All ROS applications rely on ROSCORE which oversees handling all coordination between the different parts of ROS application. If its component fails, then the whole ROS system goes down. This implies that it does not matter how well your ROS application has been constructed. If ROSCORE dies, Autoware and any application alongside dies which is something to bear in mind when configuring ROS.

Figure 3. RVIZ Visualisation Setup with Autoware

Integrating ROS with Autoware provides a way to implement a vehicle interface to allow Autoware to be able to control rFpro vehicle which is provided by autoware_msgs/VehicleCmd. This latter provides several options for how the vehicle can be controlled and each drive-by-wire interface developer will handle the information provided in a different way. Regarding the components of VehicleCmd, they are combined by the twist_gate node from several input topics which are:

•  accel_cmd, brake_cmd, steer_cmd, gear_cmd, mode_cmd, and lamp_cmd values are populated by the individual which are published by upstream components.
• ctrl_cmd contains linear_acceleration, linear_velocity and steering_angle properties.
• twist_cmd contains a geometry_msgs/Twist message which, in turn, contains linear and angular components.

Depending upon which components are enabled upstream and which options are set on them, different portions of this message will be populated. The typical methodology for how to handle this is either:

• Decide that you will only support one control method and inform your users.
• Listen to all components but create a priority order within your interface.

With current fixes on Autoware, future work and blogs will focus on map generation using rFpro sensors to load an rFpro world in place of Autoware current ROSBAG demo data.

Written by Amina Hamoud – Project Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion

References:

[1] https://www.claytex.com/tech-blog/architecture-development-to-virtual-validation-of-adas-systems-using-digital-twin-technologies/

[2] https://www.claytex.com/tech-blog/autoware-what-how-where/

[3] https://wiki.ros.org/ROS

[4] https://wiki.ros.org/melodic/Installation

[5]https://gitlab.com/autowarefoundation/autoware.ai/autoware/-/wikis/Source-Build

[6]https://gitlab.com/autowarefoundation/autoware.ai/autoware/-/wikis/ROSBAG-Demo