Week 12 - Endcourse Projects

In this lab session we will describe three end course projects and choose one of them for completion.

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Føns

Goal

Discuss and settle on an endcourse project.

Plan

First we will briefly sketch each endcourse project idea, and then give a more detailed view of each project in succession.

1. End course project overviews
2. Project details - Lego Sorting
3. Project details - P2P Bluetooth Mobile Ad-hoc Network
4. Project details - LegWay Alishan Train Track
5. Chosen project

1. Project overviews

We have three ideas to an endcourse project:

• Lego Sorting machineMachine that is able to sort some types of Lego Bricks automatically. We believe we can sort the items seen in Figure 1.
• P2P Bluetooth Mobile Ad-hoc NetworkBluetooth communication module enable many NXT bricks to communicate together. Built using the Destination Sequenced Distance Vector routing protocol.
• LegWay Alishan Train TrackBuild a LegWay robot which is able to traverse the Alishan Train Track.

2. Project details - Lego Sorting

Figure 1: The different types of axles and beams that the Lego sorter must be able to sort

We have the following requirements for the sorting system:

• It should be easily extensible allowing new sorting modules to be built and integrated into the existing architecture
• It should sort at least two types of Lego pieces: axles and beams (figure 1)
• It should be completely decentralized, only running on NXT bricks with no PCs involved

We imagine the system will be split in three modules: a separator, a number of sorters and a distributor (figure 2). The separator takes any (supported) Lego piece and distributes it to the correct sorter. The sorter takes Lego pieces of a specific type (axles, beams, pins etc) and will be able to sort these pieces. The distributor will place the pieces in their respective buckets depending on the information it gets from the sorters

We will not be making the separator module in this project so the actual system will only contain the distributor and sorters. As a result, the Lego pieces must be sorted into groups before they can be used with the system.

Figure 2: The envisioned architecture of the Lego sorter consists of three modules: a distributor, a number of sorters and a separator

3.1 Platform

Each module requires its own NXT. Furthermore, a separate NXT will be required for each sorter. This brings the minimum number of NXTs needed to four. There will also be one or more NXTs needed to control the transportation mechanisms between the modules.

With regards to sensors and actuators what is needed is entirely dependent on the specific implementation of each module. For example, a beam sorter module may use a motor to transport the beams past a light sensor that counts the number of holes. Generally, we imagine that each sorter will need at least one motor and one sensor. The distributor module may need several due to its potential complexity.

3.2 Architecture

The distributor module will probably be a closed-loop [1] PID [2] controlled car-like thing driving around on a track.

The sorters will use appropriate NXT sensors (light, ultrasonic etc.). Each sorter will probably be an open-loop [1] system due to their inherent simplicity (though complex in construction).

3.3 Challenges

We believe the primary challenge is the physical design and construction of the system. Due to its complexity, it requires a substantial effort to design and build a system that will not only work but also be fast enough to be useful (i.e. sorting one axle per minute is useless).

The secondary challenges lie in the architecture and implementation of the distributor module. This module is the most advanced as it needs to be able to put any (supported) Lego piece, coming in any order, from any sorter, in the right bucket as fast as possible.

3.4 Presentation goal

We plan to present a working system that can efficiently sort Lego axles and beams.

3. Project details - P2P Bluetooth Mobile ad-hoc Network

This project is about building a robust and scalable communication medium that NXTs can use to communicate with eachother. There are a number of requirements:

• Should use Bluetooth for communication
• Should only use NXTs. There should be central component, like a computer.
• Should be able to scale to at least 30+ peers
• Should be reasonably fast

3.1 Platform

We need to use multiple NXTs hardware units each functioning as a peer in the Mobile Ad-hoc Network. We are required to build a software module and build routing tables inside each NXT and use this for forwarding messages trough the network. It should independent enough so that it can be used as an API for communication.

3.2 Architecture

Our envisioned software architecture can be seen in Figure 2.

Figure 2 - Envisioned software architecture for our Mobile Ad-hoc Network routing system.
A Client registers a RouterListener which then receives messages from the Router.

3.3 Challenges

There are many challenges in this project:

• Maintaining routing tables is not easy. NXT's can suddenly disappear (battery, out of range) and can suddenly appear (in range, just powered up). These updates needs to be propagated trough the network so that packages can be routed correctly.
• To allow reliable communication, some sort of TCP-like acknowledgement must be sent.
• Bluetooth devices have a limited number of connections it can maintain

3.4 Presentation goal

For this project we would like to start up 10 NXT's. These should start building a routing table and then we would like to show that one NXT can send a message to another NXT where it have to route it trough multiple peers. We would see that the message ends up at the NXT in the other end of the routing path. Then we would rearrange how the NXTs are placed, and then show that it is still possible to send a message through the network and see that it takes a different path.

We would also like to setup a special peer (a computer) where all the NXT's sends their full routing tables once a while. This way, we can draw a graph with the current routing table for all the devices.

4. Project details - LegWay Alishan Train Track

We want to create a LegWay which can traverse the Alishan Train Track.

4.1 Platform

We will only need one NXT with two motors and some sensors for making sure that we are standing upright. Sensors would probably be gyroscope, tachocounters and lightsensors.

4.2 Architecture

We believe this can be built using a behavioral model [3]. The highest priority behavior would be to make sure we maintain balance. The lower behavior will make sure we are following the track while the lowest behavior will make us move forward.

4.3 Challenges

The main challenge is to maintain the balance when beginning to climb or descend on the Alishan train track. The balance point will move forward when climbing and backwards when descending.

4.4 Presentation goal

Here we will present the robot which should hopefully be able to climb the Alishan train track. If it is not able to do that, we will show that it is able to drive up a hill and down again.

5. Chosen project

The first project we wanted to make our endcourse project was the P2P Bluetooh Mobile Ad-hoc Netwprk project. However, we made small tests that showed that it would be very cumbersome to create such a network because of:

• Each NXT can only have either maximum three outgoing connections OR one ingoing connection. This creates a master node in a socalled piconet with a maximum of three slaves.
• One could create a socalled scatternet (multiple piconets where some piconet slaves disconnect from their master to connect to another piconet, thus forming a bridge between the two piconets). However, since connection estabilishing takes a matter of seconds the resulting network would not be able to scale and thus uninteresting.

Therefore we dropped this idea.

Then there is the choice between the Alishan Train Track LegWay and the Lego Sorter. We think it would be funniest to build the Lego Sorter, since it can always stand in the Lego Room and be used to sort some Lego bricks. Therefore we have chosen that idea.

References

[1] Control Theory, WikiPedia, http://en.wikipedia.org/wiki/Control_theory

[2], PID Control, chapter 5, pp. 179-190 of  Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering

[3], Maja J Mataric, Integration of Representation Into Goal-Driven Behavior-Based Robots