Communication Subsystem

The design of the communication subsystem is a critical aspect of the project as it is required for the communication subsystem to be efficient, robust, reliable, and scalable.  The challenge lies in designing a system that will house multiple communication channels without any intermittent interference and communication range reductions, i.e., the platforms will be able to communicate with each other throughout the parking lot without any loss in link.

Therefore, we intend to use two communication links per mobile platform.

Bluetooth Link

A Bluetooth link will establish communication between the smartphone and the communication system in the mobile platform.  The user will send park and return commands via this link, as well as receive status information from the vehicle.

The link between the smartphone app and the platform was chosen as a Bluetooth link due to ease of implementation on a smartphone interface, which reduces complexity.  For the scope of this project, there are limited range requirements of this link, so the range of a Bluetooth link is not a problem.

Implementation

The Android application developed for this task utilizes the Bluetooth adapter present in the smartphone to establish communication with the Single Board Computer, which is running ROS.  This bidirectional communication requires a server, client, and a service with a specific protocol through which all this interaction takes place.

The app, called Virtual Valet, allows the user to press “Park” or “Return” as appropriate.  When the vehicle is in the entry queue, pressing “Park” is the first domino in the project.  This will initiate the planning and locomotion that will take the vehicle from the entry queue to the parking spot.  When the vehicle has reached the parking spot, the app will update its status to show that it is parked.  At this point, the user can press “Return,” which will initiate the appropriate sequences for the platform to move to the exit of the parking lot.  When the vehicle reaches the exit, the status on the app will update to inform the user that the vehicle has returned.  The commands and statuses are communicated over the Bluetooth connection between the Virtual Valet app on the users phone and the vehicle itself.

Android Application

The Android app utilizes the BluetoothChatService provided by Google for developers.  This chat service helps to establish and manage connections with remote devices by running the appropriate threads.

ROS Node

The ROS Node running on the SBC communicates with the Android app by advertising a Bluetooth service to which the app can subscribe.  All this is done through an RFCOMM socket port.

Android Application User Interface

Vehicle-To-Vehicle (P2P) Communication Link:

The P2P communication link will ensure that each vehicle is able to share data with the others.  The data being shared will aid in global planning of the vehicles. Vehicles in the parking lot will share information regarding the parking lot status in accordance with a message handling protocol. The time taken for a vehicle to identify and park in an optimal spot is significantly reduced when compared to a system without collaboration. To achieve these requirements, a mesh topology will be used which makes way for an ad-hoc network where vehicles can enter and leave without the need for authentication.

Another key aspect of the system is to eliminate the need of a central server.  Because this will have bandwidth limitations, the size of data being shared will be kept as minimal as possible.  For example, the information regarding the state of the parking lot will be a Boolean matrix instead of a full occupancy map. The local multi-agent planner will decide on an optimal spot given the binary occupancy list and the vehicle will plan a route to that spot.

The XBee Mesh Protocol

The DigiMesh protocol eliminates the need for dedicated Coordinator/Router nodes as the network is homogenous- all nodes can route data and are interchangeable. This is an apt fit for our application and eliminates the need for a central server. Our system is based on VANETs, which are ad-hoc networks that do not require a coordinator node.

Mesh Protocol Implementation for XBee Pro S2B

The selected XBee Adapter works in the 900 MHz frequency. This ensures greater range than the 2.4 GHz modules (~450 ft.) due to greater penetration power. The data we wish to transmit consists of a data structure containing the occupancy map in a string format and therefore the data rate supported (~150 Kbps) is sufficient for this application.

Xbee Dongle

Digi Xbee Pro USB Adaptor

Implementation

The entire message handling sequence is depicted in the following flow diagrams:

 

Start Flow

 

XBee Wait Flow rev1

 

 

 

ROS Wait Flow rev2

 

In these figures, the red messages correspond to XBee messages and the green correspond to ROS messages.

 

The data packets are encoded using a custom format that includes vehicle ID, data length, and checksum, which is used to determine the origin and ensure the integrity of the data.  The current data being sent is the binary occupancy list of spots.

Serial (XBee message) descriptions:

  1. HELLO: When a new vehicle enters the parking lot, it instantaneously becomes a part of the mesh network. However, to ensure a methodical approach for self-identification and registration, it sends out a HELLO message that is received by all of the other vehicles in the lot. This provides a way for the already present vehicles to know the formal identity of the new member.
  2. INTRO: On receiving a HELLO message, the vehicle that was last in queue (and had already identified itself in the network before the newcomer) sends out an INTRO message. None of the other vehicles send the INTRO except the last in queue to prevent flooding the network. They simply update their database with the identity of the new member.
  3. UPDATE: Once the incoming vehicle chooses a spot or an outgoing vehicle exits its spot, an UPDATE message is sent over the network notifying other vehicles that a spot is occupied/empty. Every vehicle updates its dictionary with the appropriate spot ID against the vehicle ID.
  4. PARKED: When a vehicle receives a PARKED message, it updates the vehicle dictionary and removes the way-points of that vehicle.
  5. GOODBYE: On receiving a return command from the user, an outgoing vehicle sends out a GOODBYE message, thereby releasing its spot. All vehicles now remove the exiting vehicle from their dictionaries.

ROS message descriptions:

  1. PARK: Collaboration node sends ‘park’ message to the multi-agent planner to obtain desired spot ID.
  2. PARKED: This message is necessary for the UI to know when the vehicle has reached its spot. Navigation sends a ‘parked’ message to collaboration node which relays this information to the UI to update the display status of the vehicle.
  3. RETURN: Collaboration node sends ‘return’ message to navigation, directing it to the exit coordinates.
  4. RETURNED: A ‘returned’ message is sent by navigation to the collaboration node which triggers a Goodbye message to be sent over the network.
  5. VV: Virtual Vehicle messages are sent by the UI to the collaboration node on the platform to which the display is attached. These aid in updating the in_queue, parking, parked, returning and returned states of the vehicles in the lot in real time.