Pi Car Comm Log

From ESE205 Wiki
Revision as of 22:10, 12 February 2018 by Cybo (talk | contribs)
Jump to navigation Jump to search

Week 3

Week 2

Title: Group Meeting and More Research

Author: Yak Fishman

Date: 2/12/2018

Hours: 5

More Python learning

Continued reading the posted links and other research

Group Meeting

Title: Raspberry Pi tutorials

Author: Jacob Cytron

Date: 2/12/2018

Hours: 5

Watched a series of great in-depth tutorials on coding Python on a RaspberryPi

Group Meeting with TA: We experimented with 3-way communication between PiCars

Title: Friday Meeting/Python Learning

Author: Jacob Cytron

Date: 2/09/2018

Hours: 3

Watched Python tutorials

Made adjustments to the Gantt chart

In-class Meeting

Title: Broadcasting Two Way Communication

Author: Patrick Naughton

Date: 2/9/2018

Hours: 2.5

Created two python scripts, send.py and recv.py to send and receive messages using python's built in socket library.

Configured the above scripts to broadcast to any device operating on the same network.

Created and updated a Github for the code.

Sending.jpeg Receiving.jpeg Broadcasting.jpeg Receiving Broadcast.jpeg

Next Steps:

  • Designing a round-trip-time (RTT) experiment to determine how long packets spend in transit.
  • Define the model we want to use to send these packets.
  • Add in another Pi to test how/if that changes the network's capabilities.
  • Define a standard name for the mesh network.
  • Experiment with sending to just a subnet rather than any available IP address.

Challenges:

  • Effectively testing RTT
  • Designing an effective, consistent model.

Title: Presentation

Author: Patrick Naughton

Date: 2/5/2018

Hours: 1

Finished up presentation on Wi Fi.

Researched how to send udp packets with python.

Next Steps:

  • Experiment with socket library

Challenges:

  • Debugging socket

Title: Meeting, NMAP, and Research

Author: Patrick Naughton

Date: 2/5/2018

Hours: 4

Met with group to discuss wifi adapter. Decided that we don't need it because it will not improve the success of our simulation. Still important when considering scale-ability to actual cars.

Used nmap to find all Raspberry Pi's in the LAN. Very slow (on the order of 10's of seconds).

Met with Dr. Zhang to discuss progress. Decided it was worthwhile to prepare a primer on Wi Fi both to help other groups get background on the project and to formalize some of our own knowledge.

A grad student mentioned the use of UDP (user datagram protocol) to exchange information. Good because it doesn't require an initialization handshake and transmits quickly. Python has a built in library (socket) that interfaces with this protocol. It also supports broadcasting to an entire subnet, potentially eliminating the need for nmap. Will research further.

Began presentation on Wi Fi.

Next Steps:

  • Complete presentation
  • Experiment with socket library
  • Calculate maximum allowable delay given car speeds (~5 m/s) and Wi-Fi range

Challenges:

  • Debugging socket
  • Getting reliable latency requirement estimates

Title: Gantt Chart, Group Meeting, Presentation, and More Research

Author: Yak Fishman

Date: 2/5/2018

Hours: 5

Finished the presentation and cleaned up the Gantt chart

Continued reading the posted links and other research

Title: Pinging all Pis and the necessity of a wifi adapter

Author: Patrick Naughton

Date: 2/4/2018

Hours: 2

Working a little bit out of order but experimented to see how we can ping all Pi's on the LAN efficiently. It appears that using an nmap package (https://www.raspberrypi.org/documentation/remote-access/ip-address.md) might work.

Given the above information, it might be wise to reorder our Gantt chart to make sure we can ping multiple Pi's on the same network before we start trying to send specific information to ensure that our solution is scaleable.

Installed babeld package and found out that there is very little support for it. Likely will not use.

Discovered that the Raspberry Pi's built in WiFi only can support 2.4 GHz (https://liliputing.com/2016/02/raspberry-pi-3-to-feature-on-board-wifi-bluetooth.html), meaning that if we want to be more accurate (adhere more closely to the 802.11p protocol), we should buy an adapter that supports 5 GHz. Will discuss in meeting

Next Steps:

  • Install nmaps and see how well it works
  • Set up a mesh network with another Pi to ensure that we can broadcast more than one way

Challenges:

  • Debugging nmaps
  • Minimizing time taken to ping everything.

Title: Weekly Meeting

Author: Jacob Cytron

Date: 2/2/2018

Hours: 1

Finished the majority of the Gantt chart during our in-class meeting.

Began work on the presentation.

Title: Project Info

Author: Patrick Naughton

Date: 2/2/2018

Hours: 1

Began work on the Gantt Chart to distribute the work load.

Began the presentation for the class presentation.

Week 1

Title: Started Learning Python

Author: Jacob Cytron

Date: 2/2/2018

Hours: 2

Watched assorted videos on learning Python

Read through more of the links

Title: Yak Week 1 Work

Author: Yak Fishman

Date: 2/2/2018

Hours: 7

Attended group meeting and discussed group goals.

Continued research into materials and read linked articles.

Began to brush up on Python for future coding we will do

Title: Pinging Over Ad Hoc Network

Author: Patrick Naughton

Date: 2/1/2018

Hours: 2

Successfully pinged one Raspberry Pi from the other one over an ad hoc network.

Configured each Pi to create an ad-hoc network on startup and assign itself a static IP address.

Relevant files:

  • etc/network/interface
  • etc/rc.local

Next steps:

Title: Ad-Hoc Communication

Author: Patrick Naughton

Date: 1/31/2018

Hours: 0.5

Confirmed that ad-hoc networking is feasible. Used one Raspberry Pi to create a Wi-Fi access point that my phone could detect.

Additionally, no Wi-Fi adapter was necessary because the Raspberry Pi model 3 comes with it's own native Wi-Fi capabilities.

Ad-hoc.png

Next steps:

  • Getting both Pi's to create ad-hoc networks
  • Ping one Pi from the other

Title: Getting Materials

Author: Patrick Naughton

Date: 1/29/2018

Hours: 2.5

Got a key to the lab so that we can access materials.

Met with group to discuss objectives and potential challenges.

Acquired 2 Raspberry Pis to experiment with in order to see how easy it is to establish ad hoc communication.

Met with Dr. Zhang to discuss progress.

Discussed potential for different demos. A "mirroring" demo may be more feasible if other groups are not as successful as hoped.

Met with other groups to see their progress.

Title: First Weekly Meeting

Author: Jacob Cytron

Date: 1/29/2018

Hours: 1

I attended the first weekly meeting. We clarified our end goals for the piCar project and talked over how we will accomplish our goals.

Title: PiCar Research

Author: Jacob Cytron

Date: 1/28/2018

Hours: 2

I read some articles on the 802.11 modules and I also read through the thesis on the DriveIt communication between Raspberry Pi cars.

Title: Yet Another WiFi Adapter

Author: Patrick Naughton

Date: 1/28/2018

Hours: 1

Found yet another WiFi adapter, this one suggested by a paper specifically about using the Raspberry Pi as an "on board unit" for DSRC in a VANET. This specific adapter, at least upon initial inspection, looks like it would be a good candidate because it has Linux support, can run in ad hoc mode (CTRL-F the documentation for ad hoc, it specifies how to set it up), and runs in the 5GHz band with backwards compatibility for the 802.11a protocol. Additionally, the authors of the paper successfully used it to establish communication on a Raspberry Pi, meaning this is possible.

Adapter: https://www.amazon.com/TP-Link-Wireless-Adapter-Archer-T1U/dp/B016K088UC

Adapter documentation: https://images-na.ssl-images-amazon.com/images/I/C1BISG1QKyS.pdf

Paper: http://www.ijste.org/articles/IJSTEV2I10148.pdf

Title: A Better WiFi Adapter and a Tutorial

Author: Patrick Naughton

Date: 1/28/2018

Hours: 1

Just found a Wi-Fi adapter compatible with the 802.11a standard. It does not come with a driver on the latest version of the Raspberry Pi, which could actually be a good thing because it means we can compile the driver ourselves (modifying open source designs to suit our needs). Links to the adapter and tutorial can be found at the end of the post.

http://us.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/us/wireless_adapters_ac600_dual-band/ew-7811utc/

This is available on Amazon (https://www.amazon.com/Edimax-EW-7811UTC-Dual-Band-Connectivity-Exceeding/dp/B00FW6T36Y/ref=sr_1_1?ie=UTF8&qid=1517199327&sr=8-1&keywords=AC600+Wireless+Dual-Band+Mini+USB+Adapter+EW-7811UTC) for about $16

Tutorial: https://layereight.de/raspberry-pi/2016/08/25/raspbian-rtl8812au.html

Link to github for open source driver: https://github.com/gnab/rtl8812au

Reference: adapters that work with Raspberry Pi: https://elinux.org/RPi_USB_Wi-Fi_Adapters

Title: WiFi Adapter and more

Author: Patrick Naughton

Date: 1/27/2018

Hours: 1.5

Based on this article (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6060057&tag=1), we should be able to use an 802.11a driver to mimic a worst case scenario 802.11p driver. The paper concludes that with minor software adjustments,

VANET solutions that are validated using this approximation will also work on real hardware with better signal quality. As long as experimenters are aware of the limitations of the presented solution, it can be successfully applied as a cost-effective tool for VANET research.

We therefore need not find an 802.11p module - a more common 802.11a module will do.

Unfortunately, finding an 802.11a module is also surprisingly difficult. However, an 802.11n module should be able to operate in 802.11a mode because they share the same frequency (5GHz). This means an 802.11n module should suit our needs, as long as we can modify the device driver to make the minor adjustments the above paper discusses. Directly below is an example of such a driver.

https://www.canakit.com/raspberry-pi-wifi.html

In addition to supporting 802.11n operation, the dongle must also support ad hoc mode. This is because that seems to be the best way to set up a network mesh among multiple raspberry pis. Instructions for doing so can be found at the following link:

http://www.ericerfanian.com/mobile-mesh-networks-with-the-raspberry-pi-part-1/

Using an ad-hoc network mesh seems to be the best available solution. DSRC/WAVE, which nearly every source cites as the way to send emergency communications between cars, is an ad hoc network (https://www.hindawi.com/journals/jat/2017/2750452/). Such a network does not rely on external routers, so even if the cars lose internet access, they can still communicate with one another.

Title: Link Dump

Author: Patrick Naughton

Date: 1/26/2018

Hours: ~10-15

Author: Patrick Naughton

Date: 1/26/2018

Link to modification article. Hopefully we can use this to modify an existing 802.11a (WiFi) module to fit our needs.

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6060057&tag=1

Author: Patrick Naughton

First log