direkt zum Inhalt springen

direkt zum Hauptnavigationsmenü

Sie sind hier

TU Berlin

Inhalt des Dokuments

Autonomous Truck Platoon: Team 1

Group members: Elias Mohammedi, Anders Hausding, Yi Xiao, Jan Remy, Yiqiang Zhang, Julian Klein, (Doan Viet Anh Cao)

Project overview

Over the course of this project, we built an autonomous truck fleet that delivers cargo on a large map both swiftly and efficiently.

Goals

Our goals for this project were:

  • A realistic road network
  • High use of platooning and efficient routing
  • Autonomous driving on realistic streets

Requirements

There were multiple necessary requirements for this project. Firstly, we had to use the system architecture, described below.

Our road network had to contain:

  • At least three trucks
  • At least one depot
  • At least four pick-up/drop-off locations

The trucks were supposed to have predefined cargo space and only make use of distance and light sensors, and cameras. Furthermore, we were not allowed to use a GPS and also handle both sensor and connection failures.

Approach

We assigned each group member to one component of our system architecture. We tried to develop all components independently. To achieve that, we defined communication protocols early on.

System architecture

We were required to develop the system in three separate components: the Webots simulation, the external controller and the backend. The Webots simulation provides an artificial world with a realistic road network on which our trucks can drive. The trucks are equipped with cameras and distance sensors, to gather information about the environment. In order to control the trucks, we had to implement an interface in C for Webots and an external controller in Ada. The central computation unit for routing and platooning is the backend that is supposed to generate the optimal drive schedule. Communication between Webots and the backend is not allowed, which forced the external controller to coordinate the trucks in accordance to the routing of the backend. There is a controller for each truck in the system, as shown below in the diagram. In order to execute the planned platooning by the backend, the controllers need to be fully connected to each other. For every connection, we use TCP.

diagram

Software design

The diagram below tries to illustrate the main data flow in our system. The trucks gather data with their sensor and send it to their external controller. The external controller receives a route with planned platooning section by the backend. Using this information, the external controller analyses the sensor data. It then computes the desired speed and the steering angle, using a PID controller. In this stage, the controllers also decide whether to join or leave platoons. In order to execute these decisions, the central control logic computes concrete control commands for the truck and sends them back to the Webots controller. Our frontend is theoretically ready for use, but does not completely work with the whole system.

diagram

Robot design

Our robot consists of multiple sensors and actuators.

Drivetrain and steering

As you can see in the animation below we use a four wheel steering to increase vehicle stability at higher speeds and achieve a low turning radius. All steering angles and wheel speeds are calculated precisely in our Webots controller. Additionally each wheel has a rotational sensor attached which we use to calculate the actual position of the truck as no GPS was allowed.

diagram

Sensors and usage

In the following image you can see our robots distance sensors and cameras with their directions.

robot_distance_sensors

Currently we are not using the distance sensors pointing sideways. They were ment to track nearby trucks and ensure safe lane switching. The distance senors pointing forward are used to perform platooning and maintain a constant distance to the next truck. The cameras are used to identify the next and previous trucks by their segmentation color to manage a platoon. They are of course also used for lane keeping and crossing detection.

Environment design

Our environment layout is defined by an Open Street Map file. This has some big advantages:

  • Copy/Paste parts of the environment
  • Can directly be used to perform routing
  • Attributes such as speed limits or street names and so on can easily be defined
  • Adaptations are easy to perform

The actual Webots environment will automatically be generated by a modified importer tool.

Resulting Webots environment

Our goal was to create an environment which is as realistic as possible but also not to complex to navigate.

robot_cameras

As you can see we use two separated highway lanes. Our crossings are coloured red for easy detection and different coloured road lines on exiting lanes. As shown in the picture a truck can enter and exit the cargo station from and to each direction as it would be in the real world.

There are also big intersections on highways as you can see in the following image.

environment_intersection

All overlapping streets (not the red crossings) are realized as bridges.

Most essential algorithms

We use multiple algorithms in order to achieve our goals.

Routing

First we perform platoon routing:

  • OR-tools is used to calculate mandatory nodes to meet time and capacity constraints to fulfill all tasks with the available trucks.
  • A shortest path will then be calculated with the Dijkstra algorithm using the mandatory nodes for each truck. This route is used as a basis for optimization.
  • Then k-shortest paths for each truck will be calculated as a basis for platoon routes. When the truck's k-shortest routes overlap between different trucks platooning on these edges is possible.
  • The final solution will then be calculated using an algorithm which will optimize for total fuel consumption. It will search until a certain timeout is reached. When a solution's fuel consumption exceeds the initial solution calculated by the Dijkstra algorithm it will be discarded. We model the fuel saving in a platoon using a function which will reach a maximum of 16 percent fuel savings at 80 km/h in a platoon.

Afterwards routing instructions will be calculated using our Open Street Map.

Navigation and position tracking

As already mentioned we use our rotational sensors on each truck wheel to track our position. More precisely we do not actually calculate a position in a geographic coordinate system as it would be with GPS, we only track the distance from the last node in our route as it's much easier and sufficient to navigate our environment. As you can imagine only using travelled distance can lead to drift over time, thus we eliminate this problem by resetting the position on the red coloured crossings.

Summary

We achieved our three main goals that were stated earlier. There are also some minor goals that we did not achieve:

  • Overtaking and lane switching (only partially but not in the end product)
  • A fully functional graphical backend
  • Track current traffic and use it to optimize our routing
  • Achieve sufficient test coverage and run system tests

Lessons learned

There were two main issues for us with this project:

  • We set goals that were unrealistically high
  • We did not manage our time very well

It took a long time to develop a fully autonomous driving truck on realistic roads, while the main focus should have been the routing and platooning. Also, we invested too much time in the routing, trying to optimize it for huge maps. In the end, due to other bottlenecks, we could only use smaller maps. Because of that, we were short on time in the end and were not able to fully achieve all our goals.

Future work

We would complete all not fully functional components, which would require a couple of days. As our system was designed for realistic environments, the next step would be to use real world maps.

Zusatzinformationen / Extras

Direktzugang

Schnellnavigation zur Seite über Nummerneingabe