build details

Show: section status errors & todos local changes recent changes last change in-page changes feedback controls

Distributed Estimation: final report

Modified 2018-05-27 by Andrea Censi

TODO for Jacopo Tani: fix images, formatting

previous task next (23 of 24) index
for:Jacopo Tanitask

The following was marked as "todo".

TODO for Jacopo Tani: fix images, formatting

File book/fall2017_projects/29_distrubuted_est/30-final-project-report-fleet-communication.md.

File book/fall2017_projects/29_distrubuted_est/30-final-project-report-fleet-communication.md
in repo duckietown/docs-fall2017_projects branch master17 commit 2fcca8c7
last modified by Andrea Censi on 2018-09-02 16:46:23

Created by function create_notes_from_elements in module mcdp_docs.task_markers.

The final result

Modified 2018-03-11 by Jacopo Tani

The video is at https://vimeo.com/259547632.

The Distributed estimation, a.k.a. Fleet messaging, Demo Video

see the operation manual to reproduce these results.

README

Mission and Scope

Modified 2018-03-11 by Jacopo Tani

With this project we enable Duckiebots to communicate with each other on centralized and decentralized wireless networks.

Motivation

Modified 2018-03-11 by Jacopo Tani

In the previous state of Duckietown, Duckiebots were individual, autonomous agents, roaming around Duckietown with no way to communicate with each other explicitly (the only method in existence is with the help of LED patterns, resulting in long interpretation times). Since the ultimate goal being an automated taxi system: Duckiebots working together picking up and dropping off customers in the optimal way; the Duckiebots need to be able to communicate with each other efficiently.

One important part of this communication setup is that it can be decentralized, using a mesh network and Duckiebots can join and leave the system without putting the whole network at risk of failing. This also allows for the network to be scaled, given network limitations.

Due to the current state of Duckietown, the communication is needed, but not limited to, fleet planning control to coordinate the fleet in a town with a predefined map.

Existing solution

Modified 2018-03-11 by Jacopo Tani

There was no prior work to build a communication system upon. Everything was implemented from scratch.

Opportunity

Modified 2018-03-11 by Jacopo Tani

Without any existing work on wireless communication, we came up and built a whole new addition to Duckietown. We implemented a fleet-messaging package that builds an ad-hoc mesh network and lets other teams send messages

Preliminaries

Modified 2018-03-11 by Jacopo Tani

We specifically picked libraries and modules that encapsulates their respective functionalities well. Therefore to fully understand what is going on under the hood, you simply need to read up on the documentation of each package used: - batman-adv - zeroMQ - protobuf

Definition of the problem

Modified 2018-03-11 by Jacopo Tani

The final goals of the project were to: 1. Create a robust wireless network that can easily be scaled to a larger fleet size and to a bigger Duckietown. 2. Build a communication framework for the Duckiebots that enables the sending and receiving of messages to and from any Duckiebot, which is connected to the above mentioned network. 3. Have a communication framework that is reusable and scalable.

For this we made the following assumptions: 1. Duckiebots can connect to a wifi network. 2. Duckiebots leave network when they are out of range or switched off. 3. If a Duckiebot is not connected to the communication network, it is not in Duckietown. 4. In a first step, the communication network is used by the fleet-planning team.

To evaluate the new framework we: 1. Compared the messages sent and received between two Duckiebots connected over the network and looked for messages dropped. 2. Tested the range of the wifi adapters to see if it is able to cover the size of a demo-sized Duckietown. 3. Test the robustness of the network by taking a Duckiebot out of range of the network and back and restarting the Duckiebot in to see if it would reconnect.

Contribution / Added functionality

Modified 2018-03-11 by Jacopo Tani

Formal performance evaluation / Results

Modified 2018-03-11 by Jacopo Tani

There are three main criterion that have to be evaluated: 1. Message transport: 1. Centralized Network: test if a simple message e.g. a string can be sent from one duckiebot to another reliably. 2. Decentralized Network: test message propagation. In a mesh network two Duckiebots (nodes) may not be directly connected, therefore we must test if a message can be propagated through the network to the correct receiver. 3. Check of dropped messages. 2. Network traffic: accurately monitor network traffic. 3. Network topology: visualize nodes entering and leaving the network reliably.

To test the first criteria: - Compared the messages sent and received between two Duckiebots connected over the network and looked for messages dropped

To test the second criteria: - Analyse packets sent on wireshark

To test the third criteria: - Tested the range of the wifi adapters to see if it is able to cover the size of a demo-sized Duckietown - Test the robustness of the network by taking a Duckiebot out of range of the network and back and restarting the Duckiebot to see if it would reconnect.

Our conclusions are summarized in the following table that was established for evaluation during the project phase. The performances in bold letters were the states the messaging-package achieved at the end of this project.

0 1 2 3 4
Message Transport Messages cannot be sent or received Strings can be sent and received on tcp Messages can be serialized and sent and received on tcp Messages can be serialized and multicast and received on pgm Messages can be serialized and multicast and received on pgm on a mesh network
Network Traffic No traffic monitored Can see traffic on the network but no useful information extracted Able to isolate duckiebot traffic Able to identify specific packets Able to visualize routing of specific packages
Network Topology (centralized and decentralized) Network cannot be established Initial Network can be established, but no new nodes can connect to the network, not robust to connection loses Initial Network can be established, new nodes can connect but not reliably, not robust to connection loses Initial Network can be established, new nodes can connect/leave dynamically, but not robust to connection loses Initial Network can be established, new nodes can connect/leave dynamically, and robust to connection loses

No questions found. You can ask a question on the website.