ITS using LEGO Mindstorm

Abstract

Intelligent Transport Systems (ITS) is a general term for information-and commuication systems aimed at making the transport sector more safe, efficient and environmentally friendly. During the recent years, cars have been equipped with numerous ITS applications such as parking assistant, cruise control and even collision avoidance systems directly interfering with the car to avoid an imminent collision. Car companies claim that autonomous cars, i.e. cars capable of driving without human interference, will be on the market by the end of the decade.

Private Rapid Transport (PRT) is an emerging public transportation branch combining several different applications developed for ITS. The main difference between PRT and more tradition public transport systems is that the vehicles are operating on demand. When customers places an order, the system will summon the closest vehicle, which will pick up the customers and deliver them at the desired destination automatically. To avoid interference with other vehicles and pedestrians, the vehicles will run along specially built guideways usually separated by levitation. The goal is to make PRT a realistic alternative to the private car by offering close to the same privacy and flexibility. To offer the same flexibility as a car, the system must provide sufficient departure and destination stations. To achieve this, the guideways are intended to form a mesh network scattered all over cities and their suburbs. However, no operational PRT systems with more than five stations exist today.

Lego offers a wide range of products spanning from more or less realistic models of trains and other vehicles to advanced programmable robots. Mindstorms is Legos robotic theme, which was introduced in 1998. In this thesis, I have used EV3, which is the third generation of Lego Mindstorms. EV3 features many different advanced sensors and both powerful and accurate servo motors that can be connected to and controlled by the EV3 intelligent brick. By installing the Lego Java Operating System (LeJOS) on the intelligent brick, it is possible make programs in Java and use all the libraries included in the Java 7 Standard Edition. In addition, LeJOS makes the intelligent brick support WiFi communication, leaving developers with their imagination as the biggest restriction.

The different pieces are designed to be compatible with each other in some way, regardless of age or theme. This means that a simple Lego toy intended for children under the age of ten can be rebuilt and combined with Lego Mindstorms to become a sophisticated robot. In this thesis I have rebuilt three carriage Lego City trains into a single carriage PRT vehicles, referred to as pods. The purpose of this thesis is to determine whether or not it s possible to simulate a real world PRT control system using Lego Mindstorms in combination with Lego City trains. Because it seems like no one else have ever attempted to do this, I have made a functional PRT system on my own. The process is thoroughly described in this report and the work is mainly divided into two objectives:

1. Design a pod that can drive to a given location with smooth and realistic movements 2. Design a higher level control system that can command the pods to move efficiently and safely between stations.

1. Although I used the physical pod design from my previous project at NTNU, designing the pods control program to keep track of the pods exact location was the most time consuming individual challenge in this project. Early on, I decided to use the color sensor to count sleepers, where each sleeper in the guideway represents a unique location. Because I could not find any other projects using the Lego color sensor for a similar purpose, I had to interpret the raw data from the color sensor and process it into reliable location data on my own. When the color sensor was able to detect each sleeper exactly once, it was relatively simple to calculate the speed of the pod because I knew both the distance and time between each sleeper. To make the pod stop smoothly at a given location, I decided to use a quadratic function to calculate the required braking distance based on the current speed. I also tested different approaches, but without the same consistency as the quadratic function. In the end, the result is a pod stopping at a given location with an accuracy of 10 cm. It accelerates and brakes smoothly. To communicate with a higher level control system, I have chosen to use MQTT.

2. I have chosen to use a control system architecture consisting of a central, multiple guideway controllers and one switch operator per guideway controller.

The guideway controllers are responsible of one control area each. There is one control area per switching intersection in the guideway and pods can only enter a control area when ordered to by the guideway controller in charge of that control area. Because the guideway controllers are the only units that can allow a pod to move, it is responsible for the safety, i.e. make sure the pods do not crash into each other. In addition, the guideway controller sends switch commands to the switch operator located in its area. When a pod approaches a switching intersection, the guideway controller looks up the pods destination station in a table and orders the switch operator to switch the tracks in the correct location to route the pod the shortest path.

The switch operator receives switch orders from the guideway controller. The switch operator is always aware of the tracks direction. If the tracks are in the correct direction when it receives a switching order, no further action is taken. If not, the tracks are switched in the correct direction by rotating a motor connected to the switch handle. The central was intended to assign orders to pods automatically and constantly monitor the position of each pod to be able to detect congestion and update the routing tables. Unfortunately, I did not have time to make the central automatic. However, I have made a simple graphical user interface where an operator manually can assign orders to pods. An order can be set to repeat, which means that the pod will drive constantly between the two given stations. By assigning multiple pods repeated orders to move between different stations, a lot of interesting situations occurs at both station tracks and merging intersections.

When I tested the control system by only using a simple computer simulation, I was able to reveal some logical errors. When I had corrected all these errors, I tested the control system in the lab. This instantly exposed a lot of situations where the system failed, causing deadlocks where one or more pods stopped at wrong locations because it wasn t ordered to continue by the control system. After analyzing the results, I was able to correct most of the errors. However, I did not have time to make the system work perfectly. Nevertheless, most of the times, the system now works as intended for many minutes before an error situation occurs. By using the lab, I was able to expose errors I couldn t detect using computer simulations. In addition, it was much easier to understand the source of the errors from observing the pods behaviour. Based on this experience, I have found that Lego Mindstorms is sufficiently advanced and adaptable to simulate a simple PRT control system.