Difference between revisions of "Pi Car Comm"
| Line 50: | Line 50: | ||
<h1>Design & Solutions</h1> | <h1>Design & Solutions</h1> | ||
| − | <h2>Establishing a network | + | <h2>Establishing a network</h2> |
<p>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.</p> | <p>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.</p> | ||
| − | <h2>Sending data over the network | + | <h2>Sending data over the network</h2> |
<p>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.</p> | <p>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.</p> | ||
<p>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.</p> | <p>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.</p> | ||
| − | <h2>Intra-car communication | + | <h2>Intra-car communication</h2> |
<p>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.</p> | <p>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.</p> | ||
Revision as of 20:30, 22 April 2018
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.
Results
We were able to achieve our baseline goal of establishing a network of communication between Pi Cars. They are able to send information between each other just as we hoped
Late in the semester we were informed that we would have fewer cars at our disposal so we had to designate a majority of our project time to get two working cars so we could have a functioning demo
A link to our final poster can be found here
