Project lab 1 - Project introduction

Date: 03/05/2013
Duration of activity: 10:00-18:00 --> 8 hours
Group members participating: Ole Rasmussen and Kasper Føns

1. Goal

The goal of this activity is to write a blog post (this one) that will describe the idea behind our end course project. The aim is to establish a foundation for understanding the rest of our project work.

2. Plan

This lab report contains the following sections:

• Project overview
• Project description
• System architecture
• Challenges
• Related work

In the project overview, we will describe the form of the course (and project). The project description contains an introduction to and description of the requirements for the concrete project we will be working on. In the architecture section, we will describe the high-level architecture of our proposed system. The challenges section describes the areas we believe may be troublesome. In the related work section, we describe existing work that is related to ours. This may be useful for use as reference or inspiration in the project.

3. Project overview

The work that is being reported on here and in the following blog posts is the result of an end course project carried out in the 10 ECTS semester course Embedded Systems - Embodied Agents at Aarhus University. 

The course description [1] mentions that the prerequisite for examination participation is a project. According to the course homepage [2, 3] this self-chosen project is to be carried out at the end of the course, and lab reports should be written for each activity carried out. What you are currently reading is the first of several lab reports for our project.

Our concrete project is carried out in the last quarter of the course. In practice this is the period spanning the interval 03/05/2013 - 27/06/2013. While 27/06/2013 is the deadline for hand-in of the report (blog posts), the physical Lego system must be finished at 13/06/2013 where it is to be presented to the lecturer. This means we have the first 6 weeks for designing, building and coding the system while the last two weeks are used for writing and polishing the lab reports.

4. Project description

The project we have chosen is a Lego sorting system. We have defined the following requirements for the system:

1. It should sort at least two types of Lego pieces: axles and beams (see Figure 1).
2. It should be easily extensible.
3. It should be completely decentralized, only running on NXT bricks with no PCs involved.

Figure 1: The two types of Lego pieces that our system should be able to sort. Axles (left) and beams (right).

The first requirement is a result of the time constraints on the project. As mentioned in the project overview section we only have 6 weeks to build the system. Thus, we decided to limit the scope of the system to only sorting two types of Lego pieces. The specific types of Lego pieces are chosen based on a reasonable belief that we can sort these pieces. Axles and beams, being as universal and known as they are, seems like some of the easier pieces to sort.

The second requirement may seem awkward. Why build an extensible system when it will only be sorting two types of Lego pieces? The reason is independent developability. By architecting the system so that it is easy to add new sorting functionality we are, by the definition of extensibility, also making the system independent developable. A result we are able to develop the different components of the system in parallel and integrate them later.

The last requirement enforces certain restrictions on the system architecture. Specifically we want the system to be deployable and usable in scenarios where there are not any PC's around. One does not want to connect and configure a PC just to sort a few Lego pieces. This requirement also has an impact on the design of the system. For example, it is practically impossible to use processing-intensive technologies like image analysis and recognition in a decentralized system - NXTs alone just are not capable of holding or processing the amount of data required. Therefore, to incorporate such technologies one or more PCs are usually included as the data processor(s) as is done in e.g. [4] and [5].

5. System architecture

We imagine the sorting system will consist of three modules: a feeder, a number of sorters and a distributor (see Figure 2). The feeder takes any (supported) Lego pieces and feeds (distributes) them to the correct sorter. The sorter takes Lego pieces of a specific type (axles, beams, pins etc.) and will be able to tell the difference between these pieces. The distributor will place the pieces in their respective buckets depending on the information it gets from the sorters.

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

5.1 Hardware

Due to the extensibility requirement for the system it will probably be the easiest to have a separate NXT for each (sub)module. Thus, one NXT is required for the distributor and each sorter must have its own NXT. Bearing the project scope in mind this brings the minimum number of NXTs needed to four. Additionally there will also be one or more NXTs needed to control the transportation mechanism 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 complexity.

6. Challenges

We believe there are challenges both in the physical design, construction and coding 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). It also requires lots of time and skill to build a complete and working sorting system since it consists of many of different parts that must be interconnected.

7. Related work

In the world of Lego constructions there is one person who everyone talks about; akiyuki [6]. This guy has built some of the most advanced Lego machines in the world, including the infamous great ball contraption [7]. His repertoire includes two Lego sorting machines; the axle sorter [8] and the vision guided brick sorter [9].

Akiyuki's axle sorter runs on a single motor and sorts Lego axles using only mechanics. No sensors or PC's are involved. We imagine we will use his machine for inspiration in building our own, especially with regards to the "feeder" part which has the responsibility of feeding the sorting mechanism with a single Lego piece at a time.

The vision-guided sorter is in a whole other league. Apart from being very slow, it also requires an external PC and web camera to run the image recognition. This is very different from our system, but we mention it here anyway since it's a fine example of what a system much more advanced than ours runs and looks like. 

8. Next lab

In the next lab we will start the project by doing preliminary investigations on the design and architecture of our system. We will do this by building prototypes of parts of the system to gauge the effort and time required. Hopefully we will gain insight into the challenges that lie ahead and can use this knowledge in the weeks to come.

9. References

[1] “Embedded Systems - Embodied Agents, Digital Control in a Physical World (Q1+2) - Search Course,” AU Course Catalogue. [Online]. Available: http://kursuskatalog.au.dk/en/coursecatalog/Course/show/26923/. [Accessed: 04-Jun-2013]

[2] “Embedded Systems - Embodied Agents, End Course Project.” [Online]. Available: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson11.dir/Lesson.html. [Accessed: 04-Jun-2013]

[3] “Embedded Systems - Embodied Agents (DigitalControl) 2013 - End Course Project.” [Online]. Available: https://services.brics.dk/java/courseadmin/DigitalControl/pages/End+Course+Project. [Accessed: 04-Jun-2013]

[4] T.-H. Lee, “Real-Time Face Detection and Recognition on LEGO Mindstorms NXT Robot,” in Advances in Biometrics, vol. 4642, S.-W. Lee and S. Li, Eds. Springer Berlin Heidelberg, 2007, pp. 1006–1015

[5] A. C. Parietti Filho and M. B. R. Vallim, “Recognition and Separation of Objects on a Lego Mindstorms NXT Conveyor Belt Using Log-Polar Transform and Artificial Neural Networks,” in Robotics Symposium and Latin American Robotics Symposium (SBR-LARS), 2012 Brazilian, 2012, pp. 290–295.

[6] “LEGO TECHNIC - Akiyuki blog,” 17-Jun-2013. [Online]. Available: http://legokarakuri.blog91.fc2.com/. [Accessed: 17-Jun-2013]

[7] “LEGO Great Ball Contraption (GBC) Layout 2012.9 - YouTube,” 17-Jun-2013. [Online]. Available: http://www.youtube.com/watch?feature=player_embedded&v=sUtS52lqL5w. [Accessed: 17-Jun-2013]

[8] “LEGO Axle Sorter AS-L40A - YouTube.” [Online]. Available: http://www.youtube.com/watch?v=fM9qGZCc4DY. [Accessed: 17-Jun-2013]

[9] “LEGO Mindstorms NXT Vision Guided Brick Sorter ver1 - YouTube.” [Online]. Available: http://www.youtube.com/watch?v=6lZ9rSZwDzE. [Accessed: 17-Jun-2013]

Read More

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

Read More

Week 11

In this lab session we will experiment with the LeJOS behavior architecture.

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

Goal

To complete the exercises for Lego Lab 10.

Plan

Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:

1. BumperCar
1. Testing what happens when the touch sensor is pressed
2. Implement an exit behavior
3. Investigate arbitrator
4. Move sampling of the ultrasonic sensor to another thread
5. Modifying DetectWall behavior to first move backwards
6. Modifying DetectWall to allow activation while turning
2. Implementing dynamic prioritization - Motivation functions

1. BumperCar

1.1 Touch sensor pressed, what happens?

We have installed the sample program "BumperCar" from LeJOS. We have a ultrasonic sensor in front and a touch sensor dangling that we can manually touch to simulate the robot bumping into something (Figure 1).

Figure 1 - Our robot design. Notice that only the front ultrasonic sensor is used and the
touch sensor is manually pressed.

There are three types of reactions when pressing the touch sensor:

1. Pressing and releasing touch sensor very fast
   The robot will turn right and then go forward again. Looking into the source code of the program, this happens because the DetectWall behavior want's to take control, but when the DriveForward behavior exits the action method, DetectWall no longer want's to take control. Since the DriveForward behavior contains a bug, where it only stops the left motor when being interrupted  the robot turns left until the left motor is again told to move forward. This is fixed by stopping both right and left motors in the DriveForward behavior when interrupted.
2. Pressing and holding the touch sensor for a while
   Here the robot will move backwards for a little while and then turn right. This happens because the DetectWall behavior has higher priority than the DriveForward behavior. The DriveForward behavior gets suppressed and the DetectWall behavior gets control. It is the one that backs off and turns.
3. Pressing and keep holding it down
   Here the robot will keep driving backwards and turning. This happens because DetectWall always wants control and it has higher priority.

1.2 Implementing an exit behavior

Here we should implement a behavior which wants to have control when the ESCAPE button is pressed, and when its action is called, will call System.exit(). Notice that this kind of behavior is a bit strange, and really should be implemented using a listener on a Button outside of the Arbitrator class.

At the lecture we were shown that the DetectWall behavior does not respect calls to the suppress method. Therefore if the DetectWall behavior is executing its action method, then when pressing the ESCAPE button nothing will happen, since DetectWall  ignores all calls to suppress. We need to implement correct suppression handling to fix this issue.

Our implementation of the exit behavior can be seen in Figure 2.

Figure 2 - Exit behavior implementation. Wants to take control if ESCAPE is pressed,
exits the system if action is called.

We tested the implementation and it behaved as we expected. When the DriveForward is active and we quickly touch the ESCAPE button, DriveForward is stopped, but then the ExitBehavior no longer wants to take control, just as in section 1.1. This was as expected. We also expected that the DetectWall behavior would not respect the suppress method call, which we also saw in our testing.

We modified DetectWall behavior to respect the suppress method call, Figure 3 shows our final implementation which worked beautifully (i.e., it was suppressed immediately when the ESCAPE button was pressed).

Figure 3 - Implementation of DetectWall which respects call to the suppress method.

1.3 Investigate Arbitrator

We are asked to investigate if the takeControl method of DriveForward is called when DetectWall's takeControl method returns true. We will do this by examining the Arbitrator implementation.

Inside the Arbitrator there are two threads running. One is the main thread which calls the Arbitrator.start() method. This thread is responsible for calling the action() method of a behavior. The other thread is a thread inside the Arbitrator called Monitor. The monitor thread samples the takeControl method on the registered behaviors and stores what behavior should become active next. See Figure 4 for the code.

Figure 4 - The Monitor thread implementation inside the Arbitrator class.
When a higher prioritized behavior wants to take control, lower ones are not asked. 

The monitor calls the takeControl() method on each behavior starting from the highest prioritized one. As soon as a behavior returns true, the monitor stores this in a field and stops checking lower prioritized behaviors. This means that if DetectWall returns true in its takeControl() implementation, the takeControl method of the DriveForward behavior will not be called. That answers this question.

1.4 Move ultrasonic sampling to separate thread

The takeControl method is obligated to return its results as fast as possible. Since the DetectWall behavior samples the ultrasonic sensor, it must wait approximately 25msec for a ultrasonic burst to be sent and received. This is too long and in this section we will move this sampling to a new thread, the UltrasonicSampler thread. Figure 5 shows the complete DetectWall implementation with our UltrasonicSampler thread inside.

Figure 5 - DetectWall with UltrasonicSampler to avoid waiting too much in the takeControl method.

Notice that we have set the lastDistance to Integer.MAX_VALUE as a first value before the first sample is registered. Also notice that the field is declared volatile, which indicates that the value will be used by different threads. The UltrasonicSampler is set to be a daemon thread, so that the system exists correctly if the main thread stops. It works as expected, though the change can not be observed by looking at the robot running.

1.5 DetectWall to reverse a second before turning

Here we are asked to change DetectWalls action to first reverse for one second and then turn. This should be a straightforward implementation, but we need to consider that we can be suppressed doing both actions.

Our implementation can be seen in Figure 6.

Figure 6 - DetectWall action. Implements reverse for one second while still handling suppression calls.

It worked as expected. We could suppress it and it went backwards for approximately one second. Notice that we removed BumperCar.leftMotor.rotate(-180, true) since this would only make it go reverse for another 180 tacho counts.

1.6 Modify DetectWall to allow second activation while turning

This time we are asked to allow the DetectWall behavior to activate while it is turning. We will implement this by suppressing ourselves, if the touch sensor is pressed, while we are active and turning. When we suppress ourselves we exit from the action method, after which the DetectWall behavior should once again be chosen in the Arbitrator. Our implementation can be seen in Figure 7.

Figure 7 - DetectWall with reactivation

It worked as expected.

2. Implementing dynamic prioritization - Motivation functions

We have implemented the dynamic prioritization arbitrator as suggested by Thiemo Krink [1]. The algorithm is quite simple: first find the behavior with the maximum priority, and then only activate it if the priority is higher than the priority of the behavior previously selected for activation or if there's is no such previous behavior. The code for the arbitrator can be seen in Figure 8.

Figure 8 - The dynamic prioritization arbitrator

For the behaviors the only interesting change is in the DetectWall class (DriveForward has a constant priority). The basic idea of the takeControl method is to return a high(er) priority when the behavior is currently turning than otherwise. Assume DriveForward has a priority of x. Assume also that the base priority of DetectWall is x < y. When the bumper sensor is pressed the new priority z of DetectWall should be such that z > x while setting a variable 'turning' = true. Then, when the bumper sensor is pressed again and if 'turning' is true then the final priority of DetectWall becomes q where q > z. The result is that the arbitrator will ask DetectWall to supress itself to allow the higher-priority instance of DetectWall to run. The code for the DetectWall can be seen in figure 9.

Figure 9 - Dynamically prioritized DetectWall behavior

References

[1], Thiemo Krink(in prep.). Motivation Networks - A Biological Model for Autonomous Agent Control.

Read More

Week 10

In this lab session we will experiment with navigating a differential-driven Express Bot like car while using the tacho counters to keep track of its position and direction.

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

Goal

To complete the exercises for Lego Lab 9.

Plan

Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:

1. Blightbot
   Investigate the accuracy of a Lego car inspired by Brian Bagnall's Blightbot [1] navigating in a Cartesian coordinate system.
2. Avoiding objects while navigating
   Experiment with navigating the Lego car with the leJOS classes while avoiding obstacles.
3. Improved navigation
   Experiment with different navigation methods.

1. Blightbot

In this section we will measure how accurately our Lego car drives with the navigator class in leJOS. We will be performing two experiments: accuracy of general navigation and comparing accuracy of driving straight and rotating.

1.1 Setup

The setup for both experiments consists of the following parts: the Lego car, a whiteboard and a whiteboard marker. The car will be driving on the whiteboard with the whiteboard marker.

The car we have used for the experiment is a slightly modified version of the Express Bot (the modifications are just a result of it's usage for the Sumo competition and thus of no relevance to this experiment).

To measure the accuracy of the cars navigation we have attached a marker to the back of the car by using an elastic cord (figure 1 & 2). The car will be performing several navigational runs on a whiteboard.

Figure 1: The marker is attached to the back and is used as the "back-wheel" for the car. This way the car will partly be resting on the marker, pressing it downwards towards the whiteboard (see figure 2).

Figure 2: The marker touching the whiteboard.

The source code for the program used to generally navigate the car can be seen in figure 3.

Figure 3: Source code for a test program using the Navigator and DifferentialPilot classes.
Notice that we have shortened the path by a factor of 2 to stay within the bounds of the whiteboard.
Original code was borrowed from here.

1.2 Influencing factors

We believe the following to be factors that could influence the experiment:

• Initial placement of the car
  For subsequent runs the car must be placed on the exact same position facing the exact same direction.
• Position of whiteboard marker
  The position of the whiteboard marker may influence where on the whiteboard is drawn compared to the base of the car. It may also influence the thickness of the drawings. 

1.3 Experiment 1: comparing accuracy of several navigation runs

Figure 4 and 5 shows the Lego car performing two navigational runs.

Figure 4 - First run with our code from Figure 3.

Figure 5 - Second run with our code from Figure 3.

Figure 6 shows the result of the two runs.

Figure 6: Two subsequent runs of the Lego car with the same navigation program. The green dot marks the starting point while the two red dots mark the ending points. The blue circle is a circle with radius 4.5cm interpolated from the starting point as center and ending points a points on the circumfence.

As can bee seen on figure 6 the two runs aren't exactly matching but what's interesting is that they seem to be displacements of each other. It is important to mention that it was relatively easy to place the car on the same starting point each run but it was much harder to ensure the initial directions were the same as well. This was not unexpected though, as we mentioned it to be an influencing factor in section 1.2. From the figure it looks like the displacement could very well be due to initial differences in direction, as the runs differ already from the start on the first straight line. Had we placed the facing the exact same directions we may have had two almost exact matching runs apart from the ending point.

The ending points are interesting because they both seem to be offset from the starting position by a certain amount. The evidence for this is that the ending point closest to the starting point is the ending point for the run that goes a bit more upwards in the beginning; thus turning the direction upwards (or left depending on how you view it) displaces the ending point upwards (and out) as well. In other words it seems like the initial direction of the car determines an ending point on a circle that's surrounding the starting point. We have measured the radius of this circle to be 4.5cm based on the distance to either of the ending points for the two runs. Basically this means that had the initial directions of the car been the exact same the two ending points may have been also the exact same (almost). We are not sure what causes this offsetting anomaly but in the next experiment we will investigate Brian Bagnall observations that rotating (not driving straight) is the hard part that may be the most likely cause.

1.4 Experiment 2: Accuracy of driving straight. vs rotating

Here we will test both straight line and rotation accuracy.

1.4.1 Straight line accuracy

First we will test if we can drive straight and check that the distance driven matches the real world. The setup is a whiteboard with two parallel lines 120cm apart. We want to test if the robot can drive the 120 centimeters to hit the other line. Figure 7 shows the setup. Figure 8 shows the source code. 

Figure 7 - Test setup. Two lines parallel lines 120cm apart.
We will test if the robot will travel from one side to the other.

Figure 8 - Forward test source code. Same wheel diamater and trackWidth as in Figure 4.
The navigator is told to move 120cm forward.

We then placed the robot on the left side and started it. We did this multiple times. Figure 9 shows the overall result while Figure 10 shows the stopping positions in closeup. 

Figure 9 - The robot started from the left and moved towards the right side.
It was told to travel 120cm, but as can be seen, it did not go that far and stopped a bit short of the goal.

Figure 10 - Even though the runs don't actually hit the 120cm line, they are very consistent.
This means that the robot will travel the same distance, even though it might be a bit too short compared to the real world.

We can see that the robot does not travel the full 120cm, but it is very close (1,5 - 2,0cm off). The runs are very consistent, all traveling the approximately the same distance. We believe the distances are precisely the same, but because of small errors in the start direction and start position they end up with different distances to the black finish line.

From this we can conclude that straight-line moving is not what makes our test run in Figure 6 end up in the wrong position. We suspect the rotation accuracy might be the problem and will test this now.

1.4.2 Rotational test

We will test the rotation by telling the navigator to go forward 120cm, and then go back to the starting point. This will then be done 10 times to see if it is precise enough for that.

The source code for the rotating accuracy test can be seen in Figure 11.

Figure 11 - Test code for performing 10 runs going forward and back to start.

The actual test run can be seen in Figure 12.

Figure 12 - Test run with program from Figure 11.
It can be seen that the rotation performed is not precise.

From this we can conclude that the rotation is not precise. We are unsure of why this happens. We suspect that it might be when making fast rotation moves, that the robot does not have enough traction with the surface. We will test this in the next section.

1.4.3 Decreasing acceleration

We modified the program from Figure 11 slightly. We simply called pilot.setAcceleration(1) before giving it to the navigator. The result can be seen in Figure 12.

Figure 12 - Test run with acceleration set to 1. It took forever to complete, but is much more precise.

It can be seen that it runs better, staying closer to the start position, but it is still not perfect. This time we will test if going forward or backwards is the problem, and not the rotation.

1.4.4 Straight line again

In this test we will only go forward for 100cm, then reverse for 100cm. This is done 10 times. The code can be seen in Figure 13, the result can be seen in Figure 14.

Figure 13 - Test code for driving forward and backward. Notice that no navigator is used.

Figure 14 - Result from driving 100cm forward and backward 10 times.
Still not precise.

1.4.5 Accuracy conclusion

As can be seen from all our experiments, it seems that it is not possible to get a very precise run with the robot. Even straight line forward and reverse is not precise. It should therefore be noted, that if one is the build a map, drifiting of coordinates will occour over time.

2. Avoiding objects while navigating

The simplest way to avoid objects is to attach some ultrasonic sensors on top of the robot, and when an object is closer then some threshold, the navigator should be stopped and an avoid behavior should take command. The avoid behavior could use three ultrasonic sensors to make decisions about what way to turn, just like Maja J Mataric [2]. When the avoid behavior does not detect any more objects, the navigator is restarted. We even made a robot design (Figure 15), but then found that we were not to implement a program, just discuss how to avoid objects.

3. Improved navigation

In Enabling Your Robot to Keep Track of its Position [3] it is assumed that all moves are divided into small moves all assumed to be in straight lines. In Foreward Kinematics for the Khepera Robot [4] it is not assumed to move in straight lines. Here we can calculate more precisely where we are if we are moving in an arc.

The question is then if it is possible to upgrade Lejos navigation system to use the more precise mechanisme in [4] to get better locations. After examining Lejos code, it seems they are already using that mechanism. The DifferentialPilot fires move events and these move events describes if the move happened in an arc or in a straight line. An OdemeterPoseProvider is used to update locations and it uses the math described in [4] if an arc move happened and uses the simple math in [3] if the move was a straight move.

Therefore the optimizations of [4]is already implemented in lejos.

References

• [1] Brian Bagnall, Maximum Lego NXT - Building Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.
• [2] Maja J Mataric, Integration of Representation Into Goal-Driven Behavior-Based Robots.
• [3] Java Robotics Tutorials, Enabling Your Robot to Keep Track of its Position.
• [4] Thomas Hellstrom, Foreward Kinematics for the Khepera Robot

Read More

Week 9 - Sumo

In this lab session we will make a Sumo Wrestler.

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen

Figure 1 - Sump Wrestler Baby.
Lets see if we can take him out....

Goal

To build a Sumo Wrestling robot and win the competition. Also, learning some behavior driven robot programming.

Plan

We will execute the following in sequence:

1. Create the base sumo wrestling robot from building instructions
2. Compile, test and observe default behavior driving wrestling controller program
3. Examine the source code to determine how it works
4. Explain questions about the source code
5. Add OverturnOpponent behavior

1. Create base Sumo Wrestling robot

In this step we will construct the base sumo wrestling robot. We will build it from the instructions given here. There were no problems constructing the robot. The base robot as constructed can be seen in Figure 2.

Figure 2 - The constructed base sumo wrestling robot.

There is not much more to say to this section. Lets move on and add some behavior to the robot.

2. Sumo Wrestling controller program

In this section we will install a pre-programmed controller program onto the robot. Dependencies for the program is given here. Having installed the robot we took a test run at the wrestling area. We observed that the robot only drove forward for very little time and then stopped to change direction. We adjusted the threshold value inside the AvoidEdge behavior from 45 to 50.

Testing the robot again, we observe that the robot manages to stay inside the wrestling ring, stopping when approaching the edge. If not at the edge, the robot randomly drives forward and turns. Our robot was able to push another standard robot out of the arena - Hurrah!

3. Examine source code

Here we will examine which behaviors exists on how they work.

Examining the source code shows three different behaviors. They each have the ability to disable the behavior listed before it. They are listed below.

1. Drive behavior
2. Turn behavior
3. AvoidEdge behavior

Lets see how they are each triggered:

3.1 Drive behavior

The drive behavior is not triggered by anything, it simply drives forward, and then yields, letting other Threads be scheduled.

3.2 Turn behavior

The turn behavior is triggered every five seconds. It then stops the car, waits for it to stop, and turns it for some milliseconds in the interval [500, 1500].

3.2 AvoidEdge behavior

The AvoidEgde behavior is highest priority behavior. It has the ability to supersede all the other behaviors. It is triggered by a the LightSensor registering a light value above a given threshold.

The behavior is then to drive backwards for one second, turning left for 800msec and then stopping and staying there for 500msec.

3.3 Sum up

The given behaviors will make the robot drive around randomly, but avoiding the edge. The code is nicely structured and it should be easy to extend with new behaviors.

4. Explain questions about the source code

In the lab lesson, three questions are asked. We will try to answer them here.

4.1 Why are threads running in Daemon mode?

The behavior class extends from the Thread class. The constructor inside the Behavior class sets the thread to run in Daemon mode. The question is here, why?

The JDK Javadoc has a good explanation of what a Daemon thread is:

"Marks this thread as either a daemon thread or a user thread. The Java Virtual Machine exits when the only threads running are all daemon threads. 

This method must be invoked before the thread is started."

So if only Damon threads exists in a given Java Runtime, the Runtime will exit. This is used in the SumoBot class, so that when pressing the Exit button, the Main method will return and thereby the only thread running in non-daemon mode has halted, making the program exit.
Had the Behavior threads not been marked as Daemon threads, the program would continue to execute.

4.2 How is the SuppressNode used to suppress access to the motors in the Behavior class?

The suppression mechanism used is a hierarchy where a behavior on level is able to suppress any behavior on levels below it. This hierarchy can be seen in Figure 3.

All behaviors have access to the sensors, but only one behavior have access to the actuators at a given time. Level 1 is able to suppress Level 0, and so on up the levels.

Figure 3 - Layered behaviors

When constructing a behavior using the Behavior class, one can supply a behavior which it is able to suppress. This can be used to create a hierarchy as just described. When a behavior at level N calls the suppress method on the Behavior object, the SupressNode's suppress method is called. This method will increment a counter for the Behavior at level N-1 and call the supress method on that SuppressNode which, in turn, will increment a counter at level N-2 and so on until the bottom is reached. This will make sure that a behavior at Level [0, N-1] have a SuppressNode with a counter value larger than 0.

When a behavior wants to control the actuators, the behavior will first check if the SuppressNode given for it has a counter value at zero, if not, nothing happens.

4.3 Compare the suppression mechanism with Fred Martins' Arbiter

Fred Martins' Arbiter is a central component which registers which behaviors wants to have access to an actuator. The behaviors have a priority, and the behavior with the highest priority will have sole access to the actuator. This acomplishes the exact same thing.

5. Add OverturnOpponent behavior

This section is about adding a behavior to flip over our opponent. We did not believe in the construction of the forlift arm in the hinted building instructions. Lifting heavy robots is not an easy thing.

We wanted to build our own system. Figure 4 shows our construction with our forklift system.

Figure 4 - Custom built forklift system

We added an behavior to supersede all behaviors except the AvoidEdge behavior.

The behavior triggers every four seconds, lifting the forklift, waiting a bit, then taking it down again. See below for a run against another robot in the arena:

Read More

Week 8

In this lab session we will try to make a robot racer that races to the top of a mountain as defined in Lesson7 - Also called the Alishan Train Track.

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen

Figure 1: The Alishan Train Track

Goal

To build the fastest robot to complete the Alishan Train Track.

Plan

We will execute the following in sequence:

1. Create a super fast robot using gearing
   Constructing and experimenting with a self-built NXT robot which maximizes speed.
2. Make a control program for the robot
   Here we will create the control program for the robot created in the previous step.

1. Create a super fast robot using gearing

In this step we will construct a fast robot. In a later step, we will make this robot complete the Alishan Train Track.

We decided to develop two distinct robots in paralleled.

1. One which uses two motors and gearing on these to achieve speed. Lets call it Speedy.
2. A second robot, which uses three motors for each wheel with gearing for maximum speed. Lets call it The Rock.

1.1 Speedy

Our speedy robot can be seen on Figure 2. It has a large gearing but only two motors, one for each wheel.

It can drive at very high speeds. The gearing can be seen in Figure 3. Our idea is to make this robot "fly" up the Alishan Train Track and win the competition. As you will see, we did not manage this.

Figure 2 - The Speedy Robot. It would drive in the opposite direction.

Figure 3 - The Speedy gearing

1.2 The Rock

The Rock robot is an experiment where we wanted to use three motors to drive one wheel, which should be massively geared for an even higher speed. It can be seen on Figure 4.

Figure 4 - The Rock. As can be seen, it is massive and consists of two NXT's.
The gearing can be seen in the lower left corner.

 We did not manage to actually make The Rock drive, thereby the name. The power from the motors were too much for the gearing, which always gave in and needed to be repaired. Also, at one point, we erroneously uploaded a program for the Speedy robot to The Rock, which made a pair of the motors turn opposite of each other  This skewed both of the "sticks" which were inserted in the motors. See Figure 5.

Figure 5 - Skewed "stick" - destroyed by the force of The Rock.

2. Make a control program for the robot

Since we only made Speedy actually move, this is the only robot we have tried to implement a controller program.

Our idea was to create a sequential program which did not have any sensors. We only had to get to the top and back once, and have that on video, if we tried this enough times, one of the times should be good enough. This was at least the intuition behind our program.

We measured the distance from the bottom of the track up to the first corner, in the number of tacho counts needed. Our program would then move forward for that amount of tacho counts, make a turn, and then forward for the same amount of tacho counts.

We inserted sleeps between each action (forward, turn, ...) to see how it behaved. This is one of the test runs:

As can be seen, we did not do very well. This is not the best run we have had. We had a run which got to the second turn and fell off the track when going to the top. However, we did not get that taped.

Our robot is very susceptible to changes of the track, the battery level, inconsistencies of motor power and both wheels must drive straight.

We were not able to get it to the top. If we had more time, our next attempt would be to add a light sensor in the front to detect on which side of the line we were, and correct a little bit to stay on track.

Read More

Week 6

In this lab session we will try to make a self-balancing LEGO robot inspired by Steve Hassenplug's original Legway controlled by the RCX [1].

Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen

Figure 1: The NXTWay self-balancing robot inspired by Steve Hassenplug's Legway

Goal

To complete the exercises for Lego Lab 5.

Plan

Since our goal is to complete the exercises for this weeks lab the plan will be to complete each exercise in sequence:

1. Self-balancing robot with light sensor
   Constructing and experimenting with a self-balancing NXT robot using a light sensor
2. Choice of parameters on-the-fly
   Expand the self-balancing robot with the ability to change parts of it's source code (constants) on-the-fly via Bluetooth.
3. Self-balancing robot with color sensor
   Experiment with using the color sensor instead of the light sensor for the balancing robot.
4. Alternative self-balancing robot - horizontal NXT unit
   Constructing and experimenting with an alternative self-balancing NXT robot using a light sensor. This robot will have the NXT laying down and an overall different construction.

1. Self-balancing robot with light sensor

We will construct the LEGO robot, NXTway, suggested by Phillippe Hurbain [2] and use the java program Sejway.java from Brian Bagnall [3] on this robot. Then we will experiment with it and try to find out under which conditions it works best.

1.1 Factors

Phillippe Hurbain [2] describes three factors that may influence the workings of the self-balancing robot:

• Lighting conditions: the ambient light may influence the light readings from the sensor. If artificial lighting is used it's also possible that the type of light emitted has an effect. For example Phillippe mentions that fluorescent light is best because it emits very little infrared light that can influence the light sensor.
• Surface: the surface on which the light reflects may affect the light sensor readings. According to Philippe a clear and non-uniform surface is best.
• Equilibrium position: the robot needs to be calibrated to an offset/equilibrium that is perfectly balanced by manually placing it in the desired position. One should be careful when doing this.

1.2 Results

We have tried following Philippes advice and have observed that it was extremely difficult to make the robot balance even in a completely dark room or a room only with fluorescent light. We tried several surfaces: carpet, wooden table, whiteboard; on the carpet it turned out to be impossible to make it balance even for a second, due to the fact that the light readings from the carpet varied too little at different angles. On the whiteboard we were able to make the robot balance for a few seconds as can be seen in the video in figure 2. 

Figure 2: The constructed NXTway in action

As can be seen from the video the main problem with the balancing is that the robot isn't able to properly counteract the loss of balance; after loosing the balance it will keep driving in the direction of overbalance. This is generally the correct strategy but we believe the specific problem here was that the robot didn't generate enough acceleration to counteract the overbalancing. Since the robot was already providing max power to the motors the only way to increase acceleration that we could think of, was to use wheels of another size. Figure 3 shows the different types of wheels we tried. Of all these it turned out to be the largest wheels that were the best - this makes sense since larger wheels means the robot will move faster and thus also accelerate faster when provided with a quick burst of power. With the larger wheels we were able to make the robot balance a bit longer than before. Figure 4 shows this. The problem with larger wheels is that, due to the increase in acceleration, it will also oscillate more but we couldn't figure out a way to counteract this except adjusting the PID controller itself. We should add that we moved the sensor a bit downwards compared to the robot body to compensate for the increased distance with the larger wheels. This may be a factor affecting the experiment since the distance from the sensor to the ground isn't exactly the same with the large wheels as it is with the standard wheels - even with our height adjustment.

Figure 3: Wheel sizes used for the self-balancing robot

Figure 4: Our modified NXTway with larger wheels

To sum up: we tried following Phillippes advice but it was still extremely difficult to make the robot balance perfectly. It was impossible to make the robot balance on carpet but on a whiteboard or table it was much better. Using larger wheels improved the balancing time at the cost of more oscillations.

2. Choice of parameters on-the-fly

We have expanded the program for the self-balancing robot such that we can adjust the constants (P, I, D etc) on-the-fly from a PC instead of constantly downloading new programs to the NXT brick. This will make it more convenient to work with and debug in the future.

We have implemented the expansion by using the PCarController.java and BTControlledCar.java java classes. These classes use Bluetooth to communicate between a PC and a NXT. We modified the PC program (PCarController.java) such that we can control the following four values on our NXT: the offset (light value of balance point), kP, kI and kD where the k-values are the constants in our PID controller. The PC GUI is shown on figure 5. Figure 6 shows a video of the robot being controlled from the PC.

Since our source code is almost identical to PCarController.java and BTControlledCar.java except the addition of a few extra controllable variables and running a new Thread on the NXT, we won't show it here.

Figure 5: The PC GUI for controlling the robots constants

Figure 6: The robot being controlled from the PC (figure 5). Legend: O - offset, P,I,D -  PID constants

3. Self-balancing robot with color-sensor

We exchanged the light sensor on our NXTway with a color sensor from the NXT 2.0 set to see if it made the robot balance better.

3.1 Results

The ColorSensor
class in leJOS has different properties that affects the operation of the color sensor. One of these properties is the mode of the sensor that determines what colors it will use as flood light and also how the final light value is calculated from these colors. For our tests we tried these different modes:

• Colorfull mode: The sensor outputs all supported colors (like a rainbow) and uses these to calculate a final light value by taking an average of the color response
• Red mode: The sensor outputs a red light and reads the returned value as is
• Blue mode: The sensor outputs a blue light and reads the returned value as is
• Green mode: The sensor outputs a green light and reads the returned value as is

In colorfull mode it was impossible to make the robot balance since the light readings would only vary very little with large changes in the angle of the robot. In green and blue mode the change in light vales was much wider when varying the angle of the robot but still not as good as the variation from the standard light sensor. The mode that turned out to work the best was the red mode. This is the same mode the standard light sensor uses, and not surprisingly the results with the color sensor in this mode were the exact same as with the standard light sensor; the robot was just as good (or bad) at balancing with the color sensor as with the light sensor.

4. Alternative self-balancing robot - horizontal NXT unit

We will here test an alternative NXT segway kind of robot. We will construct the NXT Rider [4] and see how well it can be controlled with the program of Philippe Hurbain.

Results

Constructing the NXT Rider was much easier then constructing the LegWay, since the building instructions were very superior. We locked the rider in place, as suggested by the buildings instructions. The program of Phillippe Hurbain would not be able to control the third motor which moved the rider.

Our initial test run showed that the robot were able to stay upright for longer times. We began to experiment with the PID controller constants, using Bluetooth to send over new values to the NXT.

We ended up with a configuration with P = 50, I = 50 and D = 33. We could then observe that if the robot had it's balance, it would keep upright and never fall down. However, if we were to push it too much, it would not be able to accelerate fast enough, and thus have the same problem as the LegWay. A test run can be seen in Figure 7.

Figure 7: Test run of our final LegWay robot

We think that we might have been able to make the NXT Rider handle harder pushes if we could use larger wheels. We did not test this though.

References

• [1] Steve Hassenplug, LegWay
• [2] Philippe Hurbain, NXTway
• [3] Brian Bagnall, Maximum Lego NXT - Building Robots with Java Brains, Chapter 11, 243 - 284
• [4] nxtprograms.com, NXT Segway with Rider

Read More