Pi Car Comm
Contents
Proposal
Overview
The goal of this project is to establish vehicular communication between a group of PiCars. The end goal is to demonstrate this capability, specifically as it applies to collision avoidance between two or more vehicles.
Members
- Patrick Naughton
- Yak Fishman
- Jacob Cytron
- TA: Sam Hoff
- Instructor: Proffesor Mell
Objectives
- Establish an ad hoc network between many (potentially up to 10, at least 2) Pi Cars
- Use this communication capability to avoid collisions in a demonstration involving at least 2 Pi Cars
Challenges
Data Transfer Rate
As the cars will be moving quickly, one of the main challenges will be ensuring that each car can establish and modify its network extremely quickly. Thus, not just data transfer, but also network establishment speed will be important.
Additionally, simultaneously addressing all valid addresses will be difficult to do efficiently.
Security
Since we're using Wi-Fi, there is a potential for a malicious actor to transmit faulty messages that could trick a car.
Fortunately, since the Pi's and/or cars will not be connected to the internet, a malicious actor would have to be physically close to the car (within the range of the Wi-Fi), substantially limiting the number of potential attackers.
Gantt Chart and Presentation
Budget
Design & Solutions
Establishing a network
The WiFi protocol was used to communicate between cars. In order to use this protocol, the cars must establish a network over which to broadcast their messages. For this project, an ad-hoc mesh network was chosen as an appropriate configuration for two main reasons. First, it is distributed meaning that no car depends on any others being connected to the network to use it. If a given car doesn't find the network it's trying to join, it simply creates it. Second, it is adaptive. Because of the nature of driving cars, the topology of any network connecting them is subject to rapid change as they move in and out of range of each other. A mesh network can easily handle this changing structure (unlike the more static networks traditionally used to connect devices to the Internet). Each Pi Car was modified such that they would either try to join a network called "bakery" on startup or, failing that, would create such a network. This meant that as soon as a car booted up, it would be connected to all of the other cars in its vicinity.
Sending data over the network
Because the information being sent between cars was relatively simple (it can be represented as a string of bytes), sockets were used as the network interface. Each car initiated a process to listen on a socket for any messages being broadcast and created a different socket for sending messages of its own. To send a message of its own, the cars could simply send a packet of bytes to the network broadcast address, "255.255.255.255" and any cars that were listening would receive it.
As the topology of the network could change rapidly, the cars send UDP packets because UDP is connectionless (cars don't need to perform a handshake with one specific other car to send data to them). This allows cars to "fire and forget" packets across the network. Dropped packets are not that large of a concern because cars rebroadcast their status every few milliseconds, so one dropped data point will not make that large of a difference.
Intra-car communication
The Raspberry Pi often has difficulty sending multiple PWM signals simultaneously, and therefore was not a suitable board to control the physical elements of the car, namely the steering servo and ESC. Because of this, an Arduino Uno was used to interface between these hardware components and the Pi. The two boards communicated over serial.
Resources
An Instructable on how to build a Pi Car can be found here. It includes parts needed- both 3d printed parts and parts ordered, as well as a step by step guide to putting the car together.
Our GitHub with all code used in this project. Documentation provided.
Here are two tutorials on Creating an Ad Hoc Network on the Raspberry Pi and Socket Programming.
Here is a link to our UML.
Results
We were able to achieve our baseline goal of establishing an ad network of communication between Pi Cars. As shown in the picture below of an iphone finding a network setup by a Pi.
They are able to send information (up to 4 KB) to and from each other just as we hoped. Below is two pictures of one pi sending a series of texts and a different pi receiving the messages and displaying them proving our network works
Our biggest limiting factor was the hardware, and ultimately led us to make critical decisions about our demo. Below is a picture of the main car we were using
The batteries on the cars weren't always so reliable, and in fact, one of them became too discharged and unusable during our demo. Most of the cars we were using were not identical and the motors of the two cars we were using were vastly different. Because of this, our originally planned demo of having several cars driving around each other without colliding was not feasible.
Though we weren't able to have one car follow another car, we have the code and network set up to allow that. We were able to implement a demo in which we drove two cars around and those cars sent information to a stationary raspberry pi. The cars were sending values representing how much throttle they had and how much they were steering. If the cars were identical, then they could use this sent information to replicate it and theoretically follow the other car. But because the motors were different, an arbitrary increase in the throttle of one Pi Car has a much different effect than on the other. Instead, we had the stationary Raspberry Pi hooked up to a computer and was displaying all the different values that both cars were sending.
If we could do this project over again, we would build our own Pi Cars, with uniformity in hardware being a higher priority. We would also look into a more reliable power source.
A link to our final poster can be found here
