LÆGØLÅB-IT

End Course Project - 2nd robot, map building, ..., 3rd sound sensor...END!

2008-01-16T02:39:00.000-08:00

Date: 16.01.2008
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

Goal: finish the last details and set up the presentation for tomorrow

Plan:

build an exact copy of the robot;
implement and debug MapBuilding;
test the communication between the two robots;
prepare a demo-show for the presentation.

After we have retrieved all the Lego bricks (borrowing from everyone the missing pieces), in less than an hour we succeeded in cloning our robot.

MapBuilding
In our idea every robot has to keep the positions of all the party that it visited.
Every party can be considered just a couple (x, y) in the absolute coordinates system. We implemented this idea as an instance of the class Localization.
A map is then simply a list of these locations.
The problem of building the map is strictly connected with that of communicating the position of the party discovered.
This allowed us to merge the implementation of the management of the Bluetooth connection and the building of the map in the same class.

Subplan:

add a 3rd sound sensor on the rear of the car
test if this modification improves the performance

3rd Sound Sensor
We noticed that sometimes our robot behaves in an unwanted way. When the robot is directed on the opposite side of the sound source, and close to a wall, while trying turning it would see the wall with the ultrasonic sensor, and avoid that continuously, while actually going far from the sound source.
We thought that we could avoid the problem by putting a third sound sensor on the robot's back, and using it only when there is a sensible difference between front sensors and rear sensor readings.

We implemented a new behavior, called Party Behind, which is connected to the Sound Perceiver as input, and is activated only when a sound source can be heard from behind the robot louder than on front.
We had then to had some more tricks to add. We previously had moved motors in the back of the robot in order to reduce noise on sensors. By putting a sound sensor on the back we made the robot continuously spin.
We then tried increasing the threshold needed between front and read sensors, but in this case, when the robot was going slowly, this behavior didn't work.
Then, as final solution, we added a trick inside the Sound Perceiver class. The Sound Perceiver class queries motors to know if they are moving or not. If they are, a fixed value is subtracted from rear sensor, otherwise not.
This is not an accurate solution, and therefore we couldn't use that for front sensor, that need to be accurate, but we decided to keep it for this experimental behavior.

Conclusion:
The Party Locating capability of our robots is ok, although it works better only for some kinds of sound.
We completed a working prototype of our original idea, but we still miss some details.
We should have worked more on motivations, to make robots less deterministic, and we should have tested the behavior of a big flock, but we didn't have time to test (and request enough NXTs).

File (all the project - under license GPL3):
PartyRobotsProject.rar

End Course Project - Software Design

2008-01-13T03:15:00.000-08:00

Date: 13.01.2008
Duration of activity: 6 hours
List of participants: Alessandro, Daniela, Samuele

At this point we completed testing and implementing almost every small component for our robot. We then tried to put everything together.
We had already agreed on a motivation-based architecture, because we want our robot to have different behaviors, depending on its wills (i.e. internal states, motivations).
We had still to define implementation details. We discussed many points, and we summarize here our final decisions and their motivations.

Architecture discussion
We defined four behaviors, which can be seen in the chart below, in a subsumption style.

Modules:
Each of those four behaviors gives its output to the Navigator, which is an adapter class for motors.

The lowest priority behavior is Party Searcher: its responsibility is to drive the robot toward the nearest sound source. We will use the Braitenberg strategy, already implemented and tested in previous sessions. It only receives input from Sound Sensors.

The second behavior is Party Reacher: it drives the robot toward a known sound source, when a new source is received from other agents. It receives locations from incoming bluetooth communications.

The third behavior is Avoider: it makes the robot go back when encounters some obstacle, helping it keeping track of its position. It uses the Ultrasonic Sensor.

The highest priority behavior is At The Party: it is activated only when the robot is close to a sound source, hence it uses the Sound Sensors and some sound level threshold. It acts by stopping the robot and communicating its coordinates to any other robot in range for a bluetooth communication.

Suppression order:
The Party Reacher behavior must have higher priority than the Party Searcher behavior, because if some party location is already known and not visited, there is no need for wandering and looking for sound.

The Avoider behavior has higher priority than the Party Searcher and Party Reacher behaviors, since when moving, the robot must always be careful about obstacles, in order to keep track of its position.
When stopped inside a party, instead, it is better it remains stopped, in order to avoid losing the party position. In addition to this, the only cause of the avoider detecting some obstacle when stopped inside a party is when new robots arrive to the same party. It will be other robots' responsibility to not hit the stopped robots.

The At The Party behavior must have a priority higher than the one of the Party Searcher behavior, to obviously stop the search when successful. It also must be higher of the Party Reacher behavior priority, because even if the party where the Party Reacher is leading the robot is not perfectly reached, and the At The Party behavior recognizes the sound level of a party, it could only be because of some error in Navigation class; if the reasonable sound threshold is reached while driving to some known party coordinates, instead, there is no need to continue going toward the specified location.

As already specified in previous lab sessions, Navigator class we will use is similar to the one from lejos packages, being able of keep track of robot position, but it accepts motor powers as input, instead of simple coordinates, in order to work with our Braitenberg-like sound follower.

In addition to those modules, a Map must be implemented, which is basically a collection of landmarks (in this case party locations) to remember, and some helper methods.

Motivations
As pointed out before, we want our robot to have a motivation based architecture. In the discussion above the architecture seems to be working and functional only using a simple subsumption architecture. Why do we want then to use motivation functions, instead of simple boolean activation?
What we want to obtain is the behavior of an artificial creature, so we want the motivations be conditioned by some internal state. But after defining the agents' behaviors, we noticed that those four behaviors are not concurrent, in their simple interpretation, but they must be in that precise order, to work coherently.

The idea of building a flock of agents that locates parties must then be explained. It is true that an agent which locates sound must follow a precise deterministic strategy, in order to get to one of its goals. But then, when some party locations are known to the flock, and when many robots are inside a sound source, then a complex flock behavior can be imagined.
After having found a sound source, agents could evaluate their motivation of remaining at that party according to

the number of mates in the same party and their personal willing of be in company
the time of having been stopped and their personal willing of walking a bit
the time spent and the music volume of that party and their personal willing of listening to music
the kind of music of that party and their personal taste in music (although we already decided that the capability of recognizing some features of a sound is too hard to implement).

In addition to this, not only behavior arbitration could be affected by internal motivations, but also the intensity of behavior actions.
If some agent has a low motivation for walking, it could wander slowly, or stop, even if it is not inside a party.
If some agent has an high willing of listening to music, it could low down the party sound threshold, or speed up motors, in order to more easily end up listening to some music.

Then, although a simple subsumption architecture could be enough for our project, this is why we chose to implement behaviors with motivation functions: we want our architecture to be scalable to further experiments.

Data flow
The diagram below can illustrate better data flows between modules.

Modules are the same as in the previous diagram. Arrows show directions of data flow.
This layout helps to see how inter-agents communication works.

First part of the communication - an agent founds a party:
When the "At The Party" behavior receives from Sound Perceiver (an adapter for two sound sensors) a sound level over some threshold, the robot knows it is in the range of a party. Then it tells Navigator to stop, and saves current location inside the Map. The map, then, automatically notifies the Communicator module, which broadcasts the new location to any other agent around.

Second part of the communication - an agent receives a party location:
When a Communicator module of some agent receives an incoming communication about some party location, it sends it into the Map.
The Party Reacher behavior, which polls the Map, will notice the new landmark added by some external agent, and will communicate those coordinates to Navigator module, which will drive up to that location.
When arrived to the location, Party Reacher will lose its motivation, and Party Searcher will do the rest of the job to correct possible errors in position tracking, up to when the At The Party behavior will detect a party.

We proceeded then implementing (or adapting some older classes) the most of the discussed architecture, and we left debugging and testing to the following day.

End Course Project - Location saving

2008-01-11T10:32:00.000-08:00

Date: 11.01.2008
Duration of activity: 5 hours
List of participants: Alessandro, Daniela, Samuele

Goal: Make the robot able to describe, in a two dimensional system, the location of the party where it is "dancing".

Plan:

figure out how to use the tachometer of the NXT motors;
understand how TachoNavigator works;
implement a specific Navigator to make the robot move "according to Braitenberg" and localize the resulting position;
add a function to make the robot go in a specific position in the map.
test the accuracy of our Navigator

leJOS API
The only tool we can use to determine the distance covered and the direction of the robot is the tachometer included in the NXT Motors. The leJOS API provides the interface Tachometer (implemented by MotorPort) to interact with it, containing these methods:

getTachoCount() - returns the rotation count of the wheel connected with the motor in degrees [0-360[
resetTachoCount() - resets the tachometer count to 0;

The class TachoNavigator allows the robot to travel in a specified position or along a specified distance or to rotate of a specific angle and keep track of the position: the values are updated after every movement is complete.

The central idea of this lab session is to merge the concepts of "navigation" and "Braitenberg movement": using the Navigator API provided by leJOS the only way to make the robot move is imposing the distance or the angle that the robot has to drive. On the contrary we need that the robot remembers its position after a movement imposed just setting the speeds of the motors and the driving time.

The prototype of our "BraitenbergNavigator" consists of the following methods:

public void driveArc(int speedL, int speedR);
public void stop();
public float getX();
public float getY();
public float getAngle();

The first one will be the core of the class that we are going to implement: it asks the robot to move along an arc just imposing to it the speeds of the motors and to keep track of its position. This is the main difference with the leJOS TachoNavigator and the reason why we are going to rewrite it.
The second method interrupts the movement of the robot and updates its position.
The last three trivial methods return in every moment the position and the direction of the robot.

Implementation
The driveArc method sets the speed of the motors as requested from the caller and imposes them a forward movement. Since the speeds requested as input can be negative values and the function setSpeed doesn't accept any negative values, we just flip the sign of the speed before passing it to the motor and use the method backward() to impose the movement.
When the stop function is invoked, the motors are stopped and the position of the robot is updated.

Therefore the core of the new class is the function updatePosition(). The aim of this method is to calculate the coordinate of the arrival position of the robot after it covered a bend.
The values t1, t2 in the code and in the picture below are the distances covered by the two wheels calculated from the values returned by getTachoCount() multiplied by the known diameter of the wheels.

 t1 = motorLeft.getTachoCount() * wheel_diameter / 2;

Because the distance beetween the wheel is also known, it's easy to calculate the angle and the radius of the circumference which the robot is driving on.

 
alpha = (t1 - t2) / wheel_distance;
r = (t1 + t2) / (2 * alpha);

Thanks to trigonometric functions we obtain the distance covered on the axes, relative to the starting position.

 
relative_y = r * Math.sin(alpha);
relative_x = r * (1 - Math.cos(alpha));

A rotation and a translation are sufficient to obtain the new position on the absolute coordinate system.

The next step is to add a method

public void goTo(float newX, float newY)

that makes the robot move to a position indicated by the absolute coordinates newY, newX.
We tried to implement this function using the corresponding one provided by leJOS Navigator: instancing a "normal" Navigator in the constructor of "our" navigator, resetting its position every time we call our goTo method and calling its goTo method with the position updated.
An easy test,

ournavigator.drawArc(300, 500);
Thread.sleep(2000);
ournavigator.stop();
ournavigator.goTo(0, 0);

, discloses some mistake on the code of the goTo method: the travelled distance is correct, but the car is driving in a wrong direction. It reveals that the coordinate systems of the two Navigators are not compatible. We think about two solutions which can resolve the problem:

convert the coordinate system of the new navigator to those of the old one (it seems that the angle is rotated of 90°);
rewrite enterly the code of our goTo without using the "old" Navigator.

We chose the second option after an observation: using the TachoNavigator.goTo inside our goTo, if the thread is interrupted during the execution of the latter, the position are not updated. We get the inspiration from the source code of TachoNavigator to rewrite our goTo and the resulting code is the following:

definitiveUpdatePosition();
rotate(angleTo(getX(), getY(), newX, newY) - getAngle());
float distance = distanceTo(getX(), getY(), newX, newY); // cm
int speed = 500;
driveForward(speed); // degrees per second
Thread.sleep((int) (1000 * cmToDegrees(distance) / speed)); // milliseconds
stop();

where rotate and driveForward are written using our coordinate system, thus we resolved also the first problem.

Files:
BraitenbergNavigator.java

Conclusion:
At the end of this session we have at our disposal a shiny navigator that can be used to move the robot indicating just the speeds of the motors and the travelling time.
Simple tests like that one described above proved that the error is <10 cm out of a distance of 200 cm: we think this accuracy will be sufficient for our purposes, because it's important that the robot goes in the proximity of the party and not exactly in the same position of the other robots.

Further development
Adapt the coordinate system to that one used in standard leJOS API.

References:

leJOS API (particularly the section about Motors and Tachometer) - http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/lejos/nxt/Tachometer.html
Brian Bagnall, Maximum LEGO NXT - Building Robots with Java Brains (Chapter 12 - Localization)

End Course Project - Sound follower

2007-12-16T04:31:00.000-08:00

Date: 16.12.2007
Duration of activity: 8 hours
List of participants: Alessandro, Daniela, Samuele

Plan of the day:

Design and build a prototype of sound follower robot.
Test the effectiveness of its implementation
Test sound sensor capability of working in presence of multiple sound sources.

In this session we must build an important part of our project, the component which will drive the robot toward sound sources.
We considered different options, similar to the ones met within the course.
Among those, we considered of using a single sound sensor per agent and making the robot periodically stop and rotate 360° to sample around and choose the direction to follow.
We also thought of using two sound sensors, and interpolating their readings, estimate the direction from which the sound could come.

As a first try, we chose to implement a simple robot similar to the Braitenberg's vehicle, which uses sound sensors as inputs; we made this choice because, as we have seen during the course, this model seems to be the simplest and better working model for moving according to some kind of input.
As Braitenberg states: "Braitenberg's vehicles consist of the simplest sort of wheeled robots in which sensors that are sensitive to different stimuli are wired directly to motors that drive the wheels".
Valentino Braitenberg also makes an important comment, that we must be aware of: "In these models, we assume that the sensor generates a signal that is proportional to the stimulus".
As said in previous posts, we experimented that within some range of frequencies the sound level is almost proportional to distance of sound sources.

In Braitenberg's model we must connect sensor outputs to motor inputs, but before of doing that, sensor readings must be normalized with some function.
We defined the following normalizing function:

public int normalize(int value) {
   final int MIN_VALUE = 0;
   final int MAX_VALUE = Utils.LOUD_VALUE;

   value = Math.min(MAX_VALUE, Math.max(MIN_VALUE, value));

   return Math.max(0, Math.min(MAX_SPEED, (value - MIN_VALUE)
  * MAX_SPEED / (MAX_VALUE - MIN_VALUE)));
}

This function implements a linear mapping between two ranges, the first related to sound values [MIN_VALUE, MAX_VALUE] and the second to motor speeds [0, MAX_SPEED].

where:

MIN_VALUE represents a threshold value for ambient noise, in this case 0.
MAX_VALUE represents the threshold for loud sounds. Like said in previous post, the value we used is around 70. Everything above that threshold must be considered equal.
MAX_SPEED represents the maximum speed that we want the robot's motors to have.

We built a simple robot with two sound sensors and two motors and we tried the above software.

We spent a lot of time to test, but the robot only went straight, with some random steering.
We tried changing some implementation detail, but, after a deeper analysis, we identified (at least) two major problems:

The robot always went forward. It was because the difference between the sound sensors readings was too small, compared to the difference between motor powers needed to steer toward the sound.
The robot always drove, even when there was no sound. It was because of the motors' noise.

As solution to the first problem we decided to amplify the difference between the two readings, in order to make the vehicle more sensible on sound sensor's values.
We then added twice the difference between the two readings to the maximum of the two values, obtaining a difference three times larger than it was.

About the second problem, we noticed that the motors were too close to the sound sensors, as it can be seen from the same photo as above.

As partial solution to this problem, we decided to move motors, trying to put them as far as possible from the sound sensors, to reduce their noise.

After having rebuilt our robot, and updated the code several times, we got a robot able to go toward sound.
We then performed some tests on it.

We tried at first with beeps played by old RCX bricks, but they were basically too quiet, and weren't heard from this robot.
We then tried with the frequencies we established with previous tests. Robot didn't seem to react as expected.
But when trying with those frequencies, we noticed that the robot rather followed our voices, instead of pure frequencies generated by our laptops.

We started then some tests on music, and we got better results, because of their wide range of frequencies. We also noticed that songs with electric guitars worked even better. This can be explained by the fact that the overdrive effect on guitar makes the sound wave squared, which spreads the energy of the sound among more frequencies.

Conclusion
We obtained good results and we are happy with that, we will proceed in this direction.
Next time we will try to plug into the robot some location saving capability.

References
Tom Dean, Introduction to Machina Speculatrix and Braitenberg Vehicles

End Course Project - Sound sensor general tests 2

2007-12-13T11:53:00.000-08:00

Date: 13.12.2007
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

Goal of the day: investigate on multipath fading problems of previous tests, and on frequency discerning capability of sound sensors.

In previous session we thought that the unreliability of sound sensor for certain frequencies was due to multipath fading. Since this strange behavior showed only for some frequencies, we thought that using sounds with more than a single frequency we wouldn't get the same effect.
So, we tried a test similar to the previous, but using square waves, because they are made up by more frequencies (all odd harmonics).
We used our pc as sound source again, but this time with a synthesizer software, configured with a square wave sample.

These are results we obtained with the sound source distant 50cm from the sensor
do3 -> 5
re3 -> 6
mi3 -> 7
fa3 -> 9
sol3 -> 9
la3 -> 12
si3 -> 13c

do4 -> 11
re4 -> 11
mi4 -> 11
fa4 -> 17
sol4 -> 12
la4 -> 14
si4 -> 20

do5 -> 15
re5 -> 17
mi5 -> 19
fa5 -> 17
sol5 -> 17
la5 -> 20
si5 -> 21

do6 -> 21
re6 -> 14
mi6 -> 20
fa6 -> 19
sol6 -> 17
la6 -> 20
si6 -> 17

and these at distance of 100cm
c4 do -> 4
c4 re -> 7
c4 mi -> 7
c4 fa -> 8
c4 sol -> 9
c4 la -> 11
c4 si -> 11

c5 do -> 11
c5 re -> 19
c5 mi -> 23
c5 fa -> 15
c5 sol -> 7
c5 la -> 13
c5 si -> 14

As it can be easily seen, even if these sounds are not made up by a single frequency, they are affected by the same problem, since there is no smooth change between values.
For some reason with square waves we got very low values, even if we used the sound volumes of the previous test.
We obtained constant values for a wide range of notes, and then we got changes that don't seem to follow any regular function.
In addition to this, sometimes sampling continuously same certain notes, we got really fuzzy results.

Conclusion
Using square waves we got worst results than the previous test.
We think that it is not possible to recognize the frequency range of a sound source, by computing only sound sensor readings in a naive way.
If we still want to do that, we must implement a Fourier transform algorithm, but then we should face some other hardware restrictions, like NXT sensor sampling frequency, or computational capability.
Then we decided to drop the idea of discerning sound sources according to their frequency, even if we could come back to it later. We will use only amplitude of the signal as indication for distance and direction of sound.
Next tests to be done with sounds are only tests with multiple sound sources. We plan to do these tests with a sound follower robot we will build in next sessions, since its results will be easier to understand.

References
http://en.wikipedia.org/wiki/Square_wave

End Course Project - Sound sensor detailed tests

2007-12-07T07:56:00.000-08:00

Date: 07.12.2007
Duration of activity: 6 hours
List of participants: Alessandro, Daniela, Samuele

Goal: Determine which frequencies will be produced by our sound sources, in order to maximize the sound following capability of our robots.

In this test session we wanted to do an extensive test of NXT sound sensor response on a wide range of sound frequencies. We hoped to discover some properties of some range of frequencies that can be useful for our project.
We needed at least to find some frequencies which yield sound sensor values proportional to the distance from the sound source, such that the robot can have some indication about the proximity with the sound source, using only sound sensor readings.

In this test we measured readings of sound sensor values, through pure frequencies sounds from 100 Hz to 10 kHz and were repeated putting the sensor at three different distances from the sound source, at 50, 100 and 200 cm.
As sound source we used speakers of a laptop, and we generated wanted frequencies using a small tone generator software - (NCH Tone-Waveform Generator).

The tests were performed by using a plastic cup on the sensor. As said before, plastic cups will help improving the directionality of the sound sensor, and since we will only use sound sensors with plastic cups, we performed tests under the same condition in which we will use sensors.

Values we used are not directly raw values, but they are the mean value of all samples taken during 1 second; we had to use mean values because of the very noisy lego sensor.
In some cases we also repeated tests, when we got "suspicious" readings, so oscillation of values must not be attributed to random sensor noise, it is always an almost reliable mean of values for the specified frequency.

Those are test results:

frequency: Hz	value at 50cm	value at 100cm	value at 200cm
100	2	1	1
200	4	1	2
400	9	4	9
450	16	14	8
500	30	18	11
550	41	23	14
600	53	30	38
650	52	31	38
700	50	15	13
750	85	14	37
800	81	43	11
850	91	74	22
900	90	67	45
950	93	77	93
1000	90	63	29
1500	93	81	37
2000	81	62	43
2500	90	76	57
3000	75	41	39
3500	93	47	6
4000	75	42	10
4500	93	93	60
5000	72	48	20
5500	93	65	39
6000	93	72	47
6500	80	50	29
7000	81	34	10
7062	67	32	3
7125	52	22	6
7188	36	13	4
7250	33	12	4
7375	13	5	1
7500	8	5	3
7750	7	3	3
8000	4	13	1
9000	4	4	0
10000	4	1	0

As it can be seen from this table, we sampled with high density where small variations in frequency gave big changes in readings, while skipping where responses were uniform.

These are two graphs obtained from the values above:

2D version

3D version

From the graphs above some sounds sensor features come out:

The three shapes in the graph are similar in some way, and there is a decay of readings while the sound source gets far, which is an expected result, and a required condition for our robot to work. This means that near sources will give values higher than distant sources.
It is better if we use frequencies between 1kHz and 7kHz, because sensor responses are more uniform and proportional to sound source distance.
We can notice, by looking at the red line (which corresponds to the test with the closer sound source, 50cm) that the sensor response is not precise, when pushed to high levels, which means that we must consider every sampling above 70 as "loud sound" indistinctly, i.e. using threshold around 70-80 for loud sounds.
It also comes out that there are some frequencies which are still perceived loud by the sound sensor even if they're distant (2.5kHz, 4.5kHz, 6kHz), while others fall down too fast (3.5kHz, 5kHz).

Even if this test pointed out some good characteristics of NXT sound sensor, we noticed the non uniform distribution of values, which makes us worry about the possible capability of recognizing different frequencies.

After some speculation during the tests, we figured out that the problem of that oscillation was given by the environment under which we performed tests: our small office. The sensor readings were probably affected by a phenomenon which in telecommunications field is called multipath fading.
The same sound waves that come out from the sound source arrive more than once to the sensor: first time the waves with a straight path, and immediately afterwards with a different path, after having bounced on the walls. These signals are identical, but with a phase shift, which in some cases can cause them to cancel out partly or completely.

Conclusion
We got some good results, like hints about frequencies to use for sound sources.
We will do further investigation on sensing different frequencies, and avoiding multipath fading, to clarify whether the frequency discerning capability is implementable or not.

References
http://www.mediacollege.com/audio/microphones/directional-characteristics.html
http://en.wikipedia.org/wiki/Multipath_fading

End Course Project - Bluetooth general tests

2007-12-07T03:17:00.000-08:00

Date: 6.12.2007
Duration of activity: 3 hour
List of participants: Alessandro, Daniela, Samuele

Goal: trying to get NXT bricks to communicate each other via Bluetooth^©.

Plan:

get used with leJOS Bluetooth API
activate bluetooth on NXT brick and assign a name to each robot
get two NXT bricks to communicate via Bluetooth
(only if the above test fail) get the NXT brick to communicate with PC

leJOS Bluetooth API
The package that provide all the NXT communication classes is lejos.nxt.comm.
Particularly we are interested in the classes Bluetooth, BTRemoteDevice, BTConnection.
These classes are poorly documented, so we expect for hard work...

It follows a brief description of each class:

Bluetooth - it is the main class of this package and it provides all the methods to activate the own bluetooth device, to discover other devices, create connections and communicate with them;
BTRemoteDevice - the methods in this class allows to change the parameters of the robot connected with the bluetooth: the address, the friendly name and the class which the device belongs to;
BTConnection - it represents a connection with another device: using a BTConnection instance you can open streams to write and read data from that device (on the documentation you can read that this classes are "not yet implemented", but we used them with success!).

We activate bluetooth on the devices using simply the option Bluetooth --> On/Off on the leJOS interface.

Then we try to assign a name to both of the robots, using the function Bluetooth.setFriendlyName: first of all the function gets as argument a byte array, so we build an function to convert the string into a byte array (all the utility functions and the constant variable are in the file BTUtils.java).
Applying the setFriendlyName using as input the simple string converted into an array we get a strange exception during the execution of the program...ok, no panic...let's go into the source code of the function:


public static void setFriendlyName(byte[] name) {
       byte[] reply = new byte[32];
       byte[] msg = new byte[32];
     
       friendlyName = name;
     
       msg[0] = MSG_SET_FRIENDLY_NAME;
     
       for(int i=-0;i<16;i++) msg[i+1] = name[i];          
       ...

We just figure out that there is a magic number that the argument must comply with.
After the appropriate modification to the function that convert the string, we check if the robot changed its name: yes, it works!
To trick to know the name of the robot is to search it from another device: on the screen of this one will appear the name of all the found devices.

Subplan:

send an integer from a robot to another one
send a real time produced stream of data

At this point, after we have stolen some ideas from the leJOS forum, we write the code of two program that are supposed to run in the two robots: the initial idea is just trying to send an integer value from the transmitter to the receiver. We use the stream abstraction implemented (according to the documentation they are "not yet implemented"...) on a BTConnection: openDataInputStream() returns a DataInputStream that can be used to receive data and the symmetric openDataOutputStream() returns a DataOutputStream useful to send data.
Thanks to the streams we are allowed to send any type of data: boolean, byte, char, short, int, String; all our test will be based on byte type.
Obviously we don't succeed at the first trying, but fortunetly only because of two small errors: we forgot to flush the stream after sending the byte and more stupid to refresh the screen on the receiver. After fixed these problems, it works, so we can try the second step of our subplan.
The idea is to generate a stream of data produced by a sensor of a robot, send this stream via bluetooth to the other robot and control a motor of this one using the values received. We are using the MotorPort abstraction, so at the first trying we don't perceive any movement because the scales of values are different: a normalization on the values received makes the system working.

Files:
BTTransmitterP.java
BTReceiverP.java

Conclusion:
We met the first deadline!
We succeeded to get two NXT sending data each other. This will be useful when the robots will have to communicate each other the positions of the sound sources detected. For this purpose other tests will be necessary, i.e. sending a "big" data amount and store it in one of the robot, but the goal of this session was just to prove the feasibility of the idea.

References:

leJOS Forum - http://lejos.sourceforge.net/forum/
leJOS API (particularly the section about the communication package) - http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/lejos/nxt/comm/package-summary.html

End Course Project - Sound sensor general tests

2007-11-30T05:37:00.000-08:00

Date: 29.11.2007
Duration of activity: 1 hour
List of participants: Alessandro, Daniela, Samuele

Goal of the day: Before definitely choosing our project, we had to make sure that the Lego sound sensors are enough good to be used for the physical implementation of our idea.

Plan:

Find out if the Lego sound sensors can be used to recognize the direction and/or distance of some sound source
If so, define under which conditions it works better
Plan some tests to be done later in order to clarify some details of our project

Requirements formalization - An agent of our project:

must be capable of recognizing the distance of a sound source, using the read value (amplitude).
must be capable of recognizing the direction from which a sound is spread, by using two sound sensors, or by pointing a single sound sensor in different directions.
should be nice if it was capable of distinguishing among two or more different sources, by means of their frequency - in case of a pure frequency sound - or their spectrum - in case of a mixed frequency sound.

General tests
We wrote a simple program that just outputs the reading from a single sound sensor. Then we made the first test, to see how the sensor behaves as a directional sensor.
We generated a buzz with our laptop, and moved the sensor around the room to see if values actually changed a bit. We got only slight value changes.

Then we tried to improve the directionality of the sensor, by building a paper cone around the sensor. We ran the same "approximative" test, and we got very good results: high values when directed to the source, low values otherwise.

We then built a simple tester robot. We mounted the sound sensor upon a motor,

and we wrote a program that made the sensor rotate by 90 degrees in all four directions, and sample for a while in each direction. Then print out all the mean sound values.

We tried some different volumes, or with different distance, and we ended up with readings around 60 in the direction of sound, 40 in the opposite direction, and 30 in the other two directions.

We concluded that the sound sensor behaves as we hoped (actually only for near loud sounds sources as far as we know) and it could therefore be used for our project.

We noticed that the sensibility range goes from low frequencies, around 200Hz to high frequencies over 1kHz, but the sensor has different sensibilities, depending on the frequency range, for small frequency variations.

We noticed a trivial thing also, that we didn't think of before: sound waves bounce on the wall, and are heard from the sensor as if they came from the opposite direction (this is why the sensor outputs greater values when pointing in the direction opposite to the sound source).
We plan that if this problem will affect our agents in their sound locating capability, we could build an environment for them in which sound doesn't bounce on walls, by removing walls (and we would need a very large room) or by making sound absorbed by walls (by covering walls with something).

Further tests plans:

Identify which frequencies can be used by our sound sources, in order to be geographically localizable: we will measure how the sound perception falls, by getting far from the source. We will discard then frequencies that are perceived too weakly from a reasonable distance.
Then we must analyze the sensor behavior with the presence of more than a sound source

Conclusion:
As far as we know we could build our agents. We will do further tests in some days.

End Course Project - Overview

2007-11-29T08:28:00.000-08:00

Project description:
Our idea is to build a flock of agents that are attracted by sound sources.
Any agent wants to be within the range of an audio source, together with some other agents.
An audio source is a localized point in the environment, from which sound is spread at a fixed frequency.
The goal of this project is to simulate an artificial population led by specific motivation (our creatures will be constantly hungry for sound waves!) and not merely to create a device that finds sound sources.

Agent description: an agent is able to

wander randomly in search of audio sources
build a partial map of the environment
communicate with other agents to help them finding audio sources

and possibly

have different preferences on found audio sources
look for other agents, when it is alone

Required material:
Each robot should be equipped with two motors, a bump sensor (in order to approximately keep track of directions), and at least two sound sensors.
We cannot be yet sure about the exact number of sound sensors needed, or if we will need to add something to agents.
We will need at least three robots to run the network at the end of the project, but for the main part of our work we will use only one.

The environment should then contain some small audio sources, which we will try to build from a cheap loudspeaker and a Lego^© RCX brick (which are easier to find in the Lego room).

Main challenges:

Make the Lego sound sensor a directional microphone
Use the microphone to figure out the distance of audio sources
Build an audio source from a Lego RCX brick and a simple loudspeaker
Collect audio samples to distinguish different frequencies
Use the bluetooth to make agents communicate

Overall plan (with deadlines):

Bluetooth general tests	06/12
Sound Sensor tests for direction sensibility, distance / amplitude function, frequencies spectrum analysis	08/12
Sound locator robot	13/12
Location saving and map building	17/12
Multi-agent interaction	07/01
Build environment with sound sources	10/01
Final tests	15/01

NXT Programming - Lesson 10

2007-11-28T12:42:00.000-08:00

Date: 22.11.2007
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

Goal: Identifying the advantages of a motivation based behaviour in an agent

Plan:

rebuild robot
get used with the subsumption API of leJOS NXJ
test the sample program
test with bump sensor pressed
add PlaySound

We rebuilt the robot following the classical model described on the Lego^© handbook to add the bump sensor.

The Behavior interface was simple to understand, but we spent more time to analyze the code of Arbitrator. After having realized how it is supposed to work, we uploaded the code and tested it.

On a trivial test, it showed no undesired effect, but when testing, as suggested, with the bump sensor pressed, it stops. This is because, how the Behavior tutorial says, "it executes the action() method of that behavior once and only once".
Since the array of Behaviors is visited from right to the left, and the visit is interrupted whenever a behavior wants to take control, takeControl methods of lower priority Behavior are not called any more.

Before trying to fix that unwanted behavior, we adapted the PlaySound to implement the Behavior interface, and added it as an high priority behavior, as usual.
That was pretty easy, and worked as usual. It didn't happen that a lower priority behavior is still active when it is suppressed, but we tried to figure out when it could happen:
If the BehaviorAction thread is paused (by the JVM or explicitly) before the Behavior action() method ends, while inside the Arbitrator thread a Behavior with higher priority (PlaySound, in this case) triggers, it can cause some problems.
In this case, the suppress method of the Behavior is called while the action method execution is paused, possibly inside a Thread.sleep() instruction, so it wouldn't stop the action execution from this point to the end. Then the higher level action execution is queued, and will be called when the action method terminates. But in this case, the suppress() method wouldn't be called.
In this case, this issue cannot easily affect the overall Behavior of the robot, since the action method of the HitWall behavior ends with two motor.stop(), but in general it can often cause unexpected behaviors, for instance if the higher priority behavior accesses the motors.

New plan:

Implement the suggested arbitrator strategy
Analyze possible problems of the implementation
Try the motivation strategy

We changed all behaviors, removing the suppression methods and using a Thread strategy: this time Arbitrator interrupts the executing thread to suppress the associate behavior. Because the suppress method is no more used by Arbitrator we put its signature out from the Behavior interface. We created another interface (MotivationBehavior.java) and adapt all the classes for the motivation behavior architecture: for example, this is the resulting PlaySounds.java.

We didn't have time to try a different strategy where the motivation value is based on dynamic factors like the alive time of a behavior.

NXT Programming - Lesson 9

2007-11-16T04:27:00.000-08:00

Date: 15.11.2007
Duration of activity: 4 hours
List of participants: Alessandro, Samuele

Goal of the days: Investigate how a Lego NXT robot can keep track of its position and navigate avoiding the obstacles

First plan:

measure the physical characteristics of the robot
get used to the Navigator classes
think a way of measuring errors
write the test program
measure Navigator's accuracy

We used the same robot of the previous lab session: we just made little changes like removing the light sensors. This choice will turn out as a bad choice...

wheel diameter:
4.32 cm (as written on the tires)
wheel distance:
17.7 cm (measured with a plastic ruler - precision = ± 0.1 cm)

We copied the Blightbot main program to see if the parameters are correctly passed, and if the overall behaviour seems to be correct: it didn't, we had serious movement issues.
First of all we had to get strongly fixed the position of the motors, which would make the wheel distance be inaccurate.

Then we avoided that Lego pieces, other than the wheels, touched the ground and modified the precision of the robot movements.

We tested the robot again to follow the same path as the original Blightbot:
0,0
100,0
50,50
50,-25
0,0

We had friction problems with the tape on the ground. When the robot drives over it, sometimes a motor loses contact with the floor, and the robot rotates of many degrees.

Positions after three consecutive runs of the algorithm
start:

end:

We also tried to remove all unnecessary stuff, to make it more stable.
We passed to the next step anyway, to quantify the error more precisely.

Rotation accuracy quantification
In order to amplify the angle error, after a rotation, we made the robot go far (10 meters), rotate 180 degrees and then come back.
Then, the distance from the start and end point is proportional to the error angle

Nice try, but the error is in the order of ten degrees, so this test is not appropriate, we had to try a completely different approach.

New tests:
Naive test with a single 360° rotation
start

end

New rotation quantification algorithm
Simply rotate in place of 360°, and estimate the error angle.
A way to measure such a big angle is to make the robot continuously rotate of pi, and count at which iteration of this rotation it becomes aligned again, i.e. among how many iterations it loses 180°.
We added a light sensor, calibrated on a small white paper stripe, and added a control that makes the robot stop rotating of 180° when it sees again the stripe.

We found then an interesting result: at first rotations, the robot lost many degrees per rotation. Then, it precision became higher, probably because the dust that made the robot lose friction was gone after some rotations.
After 87 rotations the robot became aligned again, i.e. it made 86 180° real rotations in 87 "software" rotations.
Effective rotation: x = 180*86/87 = 177.93°
Mean rotation error: e = 180-177.93 = 2.07°

We couldn't think of a test for distance, without a ruler, since if the robot loses an amount of distance proportional to the travelled distance, every geometric shape you can think is uniformly scaled. And if it doesn't, it's even worse without a ruler.

We decided to go on with the lab session, and see if this loss of precision sensibly affects the overall behaviour of a navigator robot.

Goal:
Write an algorithm that can make drive the robot from one point to another, and avoid obstacles if any.

We wanted to use the lejos Navigator classes, and in order to do so, every robot movement must be made through that interface, otherwise it would have lost track of its position at each encountered obstacle.
We decided the following strategy: make the robot go toward the goal position, if there is no near obstacle, and whenever one is found, make it go left or right to avoid it, and then make it go again toward the goal position.

pseudocode:

while not on goal {
 sample distance ahead
 if (obstacle) {
  avoid
 }
 else {
  go to goal
 }
}

Translating into java code we couldn't use the goTo method, since it doesn't support the returnImmediately flag, so we used this little trick instead:


navigator.rotateTo(navigator.angleTo(x,y));
navigator.travel(navigator.distanceTo(x,y), true);

Then, we had to force the navigator class to update its position, because whenever we called the stop method while the robot was moving, its position was lost.

Avoid strategy:

rotate 90°
if(obstacle)
rotate 180°
if(obstacle)
 beep //stuck in an angle
 return
drive 20cm

The algorithm worked well, avoiding a single small or big obstacle to get to the goal point.

However, the navigator precision is affected by how many rotation it does, i.e. the number of obstacles it encounters on the way.
The algorithm could probably have worked even with a goal in a different room, making the robot find the door (if the door is on the right, actually), but after some rotations, the robot completely loses track of its position, and the robot randomly wanders.

NXT Programming - Lesson 7+8

2007-11-09T10:01:00.000-08:00

Date: 1.11.2007 - 8.11.2007
Duration of activity: 3+4 hours
List of participants: Alessandro, Daniela, Samuele

Note: we are writing a single lab report for two lab sessions because we couldn't complete the first lab assignment on time, so we continued the following session.

Goal of the days: "Many of the proposed experiments could be done with the Lego Mindstorms kit" - Valentino Braitenberg

First plan:

Build again the same robot car (which we always destroy for some reason at the end of each lab session)
Write the code for the Braitenberg Vehicle 2a
Test it
Invert left and right light sensors cables, so we have Vehicle 2b
Test it

The first two phases were completed at the same time. Alessandro had some ideas about the hardware structure that we didn't dare to disagree with, so we ended up with this robot
We used old light sensors, since we only have one NXT light sensor.
We didn't write a normalization with a max and min light, but only converted the light signal into the same range of the motor proportionally.

Phase 3, test:
The motors moved, but the robot didn't react to any light change. Then we remembered that old light sensor have a very tight actual range of values.
With a small program we then got the raw readings from the sensors.
minimum (ambient) light: 50%
maximum (with a lamp in front of it) light: 60%
But then, we discovered an unexpected result from an error. We forgot to passivate sensors, and obtained a much wider range:
minimum: 25%
maximum: 65%
We thought that the red led should have been used only for distinguishing colors even with low ambient light, but then we discovered that even if the red light doesn't reach any near object, it amplifies the range of ambient light.

New plan:

using light sensors in active mode
now that we understood why it is useful, write a normalization function, with a fixed max and min value
test if the robot moves this time
implementing the dynamic max and min threshold update (we have to decide how long lasting should thresholds be)
test again

Normalization:
first of all we transform the value read from the light sensor in the motor scale.

lightValue * MAX_SPEED / MAX_LIGHT

but, since we got only values starting from around 40, before applying the proportion, we apply also a translation to the light values, with the new 0 at MIN_LIGHT

(lightValue - MIN_LIGHT) * MAX_SPEED / (MAX_LIGHT - MIN_LIGHT)

Then, as we want our robot to move even when it only sees darkness, we add a fixed MIN_SPEED value to the resulting speed, and in order to do so, we reduce the space in which we project light readings

MIN_SPEED + (lightValue - MIN_LIGHT) * (MAX_SPEED - MIN_SPEED) / (MAX_LIGHT - MIN_LIGHT)

Now the robot behaves in a nice way. While testing the Braitenberg Vehicle 2b, it drives toward light, though it has a small range of sight, and often it misses the light.

Then we got to the dynamic threshold algorithm.
We had to force an explicit sleep (20 ms) in sampling threads (which we didn't include at first), otherwise we would have got too many samples.
We implemented a circular queue, which holds every sampled value, up to N, and then starts to discarding old values. We set the size of the queue as

N = MEMORY_TIMEOUT / THREAD_SLEEP,

where MEMORY_TIMEOUT (5000 ms in our tests) is the maximum life of a threshold value.

In a previous implementation we recalculated thresholds, iterating through the whole queue, at each sensor sampling. Then we thought that it's more efficient to recalculate max and min thresholds only when either the current max or min value is removed from the queue.

Our implementation worked, without a sensible slowing, but in practice its memory was actually longer than we thought. Since it is a good approximation anyway, and the delay is probably related to the way the lejos JVM manages thread, we chose to not investigate further, and leave it as it is.

Last plan for lecture 7

Move to a Multi-threading implementation

We isolated the code for the connection between a single light sensor and a single motor. This code has been then put inside a subclass of Thread.
The main program looked like

new BraitenbergConnection(sensorLeft, motorRight).start();
new BraitenbergConnection(sensorRight, motorLeft).start();

This update made the code more readable and modular, but it didn't affect the overall behaviour of the robot, even if presumably the JVM does not implement a perfect parallelization of the process.

Lesson 8 plan:

Read the assignment, which has a few questions
Test and analyze the BehaviourTest program
Refactor the previous lab session code, according to Rodney Brooks' subsumption architecture

>>What is the purpose of making these threads daemon threads?
We read the lejos doc and made a quick test: if we don't, when the main method terminates other threads keep running. And by default, threads are not daemons.

>>How is this boolean used in Locomotion.java? And how would you describe the delay method in Behaviour.java used by the behaviour threads?
In the subsumption architecture paradigm, inputs are inhibited and outputs are suppressed.
The boolean variable is used inside the delay function to suppress the input (i.e. replacing the "wakeup signal" of the returning of the delay method), and inside Locomotion functions to inhibit the output. (Yeah, in this case it is pretty much the same thing).

>>How is the suppression mechanism used in Behaviour.java to obtain controlled access to the motors? Could you think of situations where this method fails?
Every access to the motors is contained between the suppression and the unsuppression of any module that the current module can suppress. Then, if some other [more important] Behaviour needs to access the motors, that Behaviour must suppress modules which are currently using the motors.
If the modules are hierarchically ordered, it should never happen that it fails. If they are ordered in a graph-like shape, then concurrent Behaviours could be acting. In that case it should be assured that it can never happen that two concurrent modules require the same resource at the same time.

Having already adapted the Braitenberg connection between a sensor and a motor inside a single thread, we just added the Behaviour class as parent class, and adapted the code a bit, and we got a "Drive toward light" Behaviour, actually made up by two concurrent Behaviours (accessing half of the resources each).
We then rewrote the main method, according to this architecture:

It worked. Our robot now wanders around, and follows the light when it sees it. It avoids obstacles, even small ones, and plays an annoying sound every 10 seconds.

The only thing that could be fixed is that the PlaySound has no sense to be there. It should not have that high priority, which avoids sometimes the robot to correctly drive away from obstacles, other than being annoying. But we would have too few modules to make a graph with, so it's fine as it is.

Since the robot worked really fine, and showed a really precise light following behaviour, then we started to play with it and forgot about further experiments, so this post ends here.

NXT Programming - Lesson 6

2007-10-16T01:42:00.000-07:00

Date: 10.10.2007
Duration of activity: 3 hours
List of participants: Alessandro, Daniela, Samuele

Goal of the day: Build a balancing robot.

First of all we followed the Philippe Hurbain building instructions to build the balancing robot. Then we tried a naive proportional implementation, for its software, and then compared to the Philippe Hurbain code.
The result wasn't satisfying. Since its many falls, we added some to the robot, to avoid damage to it.

Then, instead of changing the constants inside of the code to make it work better, we tried some hardware modifications.

First, we tried to move the robot's weight to the bottom, to make it more firm, as the gyroscope does.
It actually was better in recovering, when it was about to fall, but it oscillated more.

Then "somebody" made us notice that it would have been easier to balance, moving the weight to the top of the robot. We then built our ridiculous robot of the week: .
It worked better with balancing, but it only could stand small oscillations. Whenever there was an error, it couldn't recover from it, since a bigger motor power should have been required (or a more precise sensor, to avoid such oscillations).

In order to build a good balancing robot, we then think that it is necessary that its mass center is located at an height proportional to motors power, depending also on the maximum angle (and speed of fall) of recovering tolerance.

NXT Programming - Lesson 5 - The Race

2007-10-06T07:53:00.000-07:00

Date: 03.10.2007
Duration of activity: 2 in the morning + 3 hours of lab session
List of participants: Daniela, Samuele

Goal of the day: come up with some idea, and decide how to compete

First of all we tried the same algorithms used the previous session, but with sensors aligned to the wheel axis.

Results where almost the same

Then we started dealing with the second idea.
As a generalization of the Y shaped robot thought the previous day, we thought to design the robot with a symmetric shape.
It would have then no need to never rotate, but it could choose to move straight in one of six directions, putting the three motors in the same shape as the sensors, and activating one or two of them, and making the others push in the opposite direction.
In this model, every motor always pushes in the direction of the movement, and two other motors push in a direction which forms an angle of Pi/6 with the movement direction.
Their summed power, regardless of friction, is then always, where p is the power of a single motor:
p + 2 * cos(Pi/6) * p = p + 2 * [sqrt(3) / 2] * p = [1+sqrt(3)] * p, which is more than 2 * p

Encouraged from the theoretical demonstration that our robot would have always run faster than any other robot with only two motors, we started building it.

And here it is. Its name is Omega3.

Then, we started all over with programming it.
We created a TriangularLocomotion class, which supports 6 directions, and a TriangularSight class, which represents the abstraction of the three outer sensors, telling in which of the 6 directions it sees the line.

The hardware test, with a simple algorithm that moved the locomotion where the sight saw the line, made it go back and forth over the line, since the concept of following wasn't injected in it yet, and it simply "stayed" on the line. It seemed promising, we went on programming.

We started with a simple stateless algorithm, that decided the direction to follow only using the sensor "sight", and the expected direction of the path (to make it know that it has to follow that direction, and can therefore apply only slight direction changes, and not going back).
We had troubles to make it move, and decided that such a structure, without any built-in concept of what is forward and what is backward, needed an algorithm with a state.

We wrote then a direction buffer class, with the methods insertLinePosition and getDirection.
It receives every sampling, makes some assumptions, and then figures out the new direction.
Internal states of this class were then coded to Forward, WaitingForBend and Bending.

When in the forward state, the robot always goes straight if it sees a line in that direction (regarding of other sensors).
When it loses the line, it moves to WaitingForBend state, because when the ahead sensor goes off the line, you expect that the sensors, which are probably out of the line, will cross it as well.
When in the WaitingForBend state, then, you just take the direction of the first sensor which crosses the line, and go in Bending state.
In Bending state, then, you are allowed to apply some correction to the trajectory, by considering the whole sensors reading, and going in the direction in which you see the line, if this implies only a small correction to the direction, or ignoring the sensor reading if it suggests to go backward.

Everything was coded, debugged and tested for hours, but we couldn't make it work. It moved, but it didn't follow any line for more than some seconds.
We are sure that in a perfect world, with continuous sensor readings, or at least more frequent and precise, our robot would have worked really nice. But it wasn't the case.

Goals reached: learned that you should try to use strange strategies to do much better than the others, only when you have backed up your old robot with your old algorithms, which could at least run as the others do.

NXT Programming - Pre race

2007-10-06T06:26:00.000-07:00

Date: 03.10.2007
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

Goal of the day: Speed up our robot.

We fixed up some minor issues, and we made some tests on the work from the previous session: the line following we ended up with was satisfying, but it was too slow.

Every algorithm we designed for our robot, since we started this course, stopped to behave how it should, when pushed to higher speed. We tried to figure out why, but some behaviors still remain a mystery.
Since the goal of this session was to speed up the robot, we decided to design and test our algorithm without starting with low speeds, but directly pushed to the maximum speed.

We made some decisions, like to turn without slowing down, after having lost the line, and hope to get back on it later. We increased motor speeds, and only decided the radius of the rotations when turning, and not the robot speed, which should be always to the max.
To bad that every change that we made just made the robot less precise, as you can see from this sadly funny video:

As it wasn't enough, while pushing the robot to its limits, it left us, smashing itself on a wall.

We then decided to change our approach to the problem.
We thought, and still are convinced, that the main problem is making the robot turn around some arbitrary axis, making it describe an arc, and assuming it rotates instantly around the center of sensors axis.

A proposal came up: never making the robot turn while moving, but only rotating at regular intervals, in order to avoid the arc problem.
A such algorithm should then make the robot go straight, sample for a certain amount of time, and try to figure out the angle of which to turn, after the sampling phase.
In that graph we represented (while not playing, on the lower part of the board) the sensor readings in function of time, and tried to imagine how can a sampling phase be interpreted, and how you can rotate the robot of a certain angle.

After those graphs, an implementation followed. Useless to say it didn't work. Too complicated, sensors too inaccurate, too much particular cases (you're already on the line, you approach the line but don't go after it, you don't see the line at all, you see two lines...).

We were about to try moving the sensors, to put them on the same axis of the wheels, to make them rotate together, but it was too late.

And another idea was around already: to put sensors in a Y shape , to make them see forward, when a turn approaches, and using the two sensors behind the robot to be sure you are aligned to the line.

Anyway, everything was delayed to the next day.
Goals reached: none.
Ideas left to try: some

NXT Programming - Lesson 4

2007-09-27T13:40:00.000-07:00

Date: 27.07.2007
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

Goal of this session: Build the fastest line follower and win the competition of the next week.

First of all we just wrote a simple program that uses the BlackWhiteSensor class, which just calibrates its threshold, and prints out values. Black is black, white is white, red, orange, green are white as well.
Since we have in mind of building our competition robot using more than one sensor, and we only have one NXT light sensor, we took some other old sensors from the lego room.
Then we modified our test program, and the BlackWhiteSensor class to check if both sensors behave the same (it could be a dangerous to do this assumption without verifying).

Values sampled by RCX and NXT light sensors are really different, so we decided to not use different types of sensors at the same time. NXT sensor seems more sensible, but we can get more of the old ones, so we had to find only an adapter for RCX sensors.
Let's try the old sensors.
We added the four sensors in a row, in place of the NXT one, and made few modifications to the robot structure (i.e. bigger wheels, to increase the speed) .
We also edited the BlackWhiteSensor class to a RCXBlackWhiteSensor, and then extended it as RCXColorSensor. It has a calibration phase which samples black, green and white, and then calculates two thresholds to distinguish the three colors.
Unfortunately it wasn't going to work: old RCX sensors sample the same value (around 34 with that ambient light) for white, green, red, and probably other colors we didn't try.
We must make the robot distinguish a green area, so we ended up with two possible solutions:

Using the NXT sensor as main sensor, and two RCX sensors for auxiliary sensors. In this case the line following algorithm actually follows the border between black and white, and not the real thick line.
Using two old RCX sensors as main sensors, and other two as auxiliary. In this case the line following algorithm would mainly have to keep the two main sensors inside the black line, and the two auxiliary sensors out of the line. To recognize the green area we can just assume that when we cannot see any black line at all, we are inside the green area.

Since we already had wondered too much about the four-sensor solution , and we believe that the first algorithm would be too slow for a speed competition, we chose the second solution.

The first naive attempt at low speed seemed to work well, so we managed to increase the speed, while keeping its line following accurate. We designed an algorithm to make the robot behave according to the four sensor readings, in a stateless way.
The following are the valid sensor states that we considered:
(one bit per sensor reading, 0 stands for sensing white, 1 for black)

forward
0110 on the line, fast forward
1111 maybe crossing another line, forward

right
0001 strange turn, probably recovering from a previous turn, gentle turn right
0011 normal turn, right
0111 possible 90° turn, fast turn right

left, same as above
1000 gentle turn left
1100 left
1110 fast turn left ->

stop
0000 no black line, stop

Every other state has been discarded as a glitch in sampling or an unknown state. In those cases the robot simply ignores the reading and keeps driving with no speed changes.

Since it wasn't that easy to make it work with higher speeds, a long discussion followed, about interpretation of robot readings , or alternative positioning of the sensors .

At last, we ran out of ideas, so we decided to stop working, and continuing later . It wasn't that bad, but we need some intuition, which is not easy to have, after four hours of work. Updates will follow.

NXT Programming - Lesson 3

2007-09-22T14:12:00.001-07:00

Date: 2007.09.20
Duration of activity: 4 hours
Group members: Alessandro, Daniela, Samuele

Goals of this session:
Trying the lego sound sensor

Very full lesson!
The first time without any problem and in which all the tools are perfectly arranged!
We start mounting the sensor on the car as described in the building instruction and trying it with the sample programs SonicSensorTest.java and SoundCtrCar.java. Ok, all is working: it's a lucky day!
We can go on with the second sample program: we think that the best way to check the ESCAPE button state also during the inner loops is to create a ButtonListener instance that modifies the value of a control variable. To make the code more compact we used the method Locomotion.drive instead of specific motion functions (forward(), left(), ...). The resulting code is the following:
SoundCtrCar.java

Before going on with the main goal of the lesson, we begin to deal with I/O methods, especially for file writing. The goal is: to sample readings from the sound sensor on a file, download it on the pc and use the recording file to create a graph.
After a quick reading to the lejos API, we make the first attempts: the primary hitch is manage the little amount of memory, because of that the program raises an exception after only three seconds of recording. We trace the amount of free memory during the program execution: the problem doesn't concern the I/O functions, but the operations used to build the strings.
Once solved this problem, found a trick to write string on file and discovered the application to download the file on the pc (thank you Gert!), we code the java implementation of Toledo's experiment:
ClapDetector.java
After tuning the threshold value (we set them 10% under Toledo's values), we obtain a really working clap detector!.
What about the sampling on the file? It seems it works, except a little detail:
in the beginning of the recording file we can see some junk characters:
maybe the flush() and close() functions of lejos implementation aren't still perfect.
After cleaning manually the file, we process it using gnuplot and we obtain this wonderful graph!

Good work, we can go home: this time the gate is open :-)

NXT Programming - Lesson 2

2007-09-19T08:58:00.000-07:00

Date: 2007.09.13
Duration of activity: 6 hours
Group members: Alessandro, Daniela, Samuele

Goals of this session:

Trying the lego ultrasonic sensor

Trying different strategies for wall following systems

After having set up our lego workstation on our laptop, we started working on our goals.

We added the ultrasonic sensor to the model, and uploaded the first sample program (Avoider).
Q: What kind of control is it?
A: A proportional control. It has indeed sudden starts and stops, and it moves jerkily.

Then we rotated the ultrasonic sensor, and tried to upload the second sample program (WallFollower). We soon discovered that there was no sample program, so we rewrote in java the two suggested solutions for it.

We tried the algorithm from the F.G.Martin's book, and it didn't work, since the model rotated too fast, and it often lost the wall, even with the gentle turn patch.

We then tried the Philippe Hurbain code. We couldn't make it work well, probably because the lego sensor often doesn't see obstacles when their surface is rotated of a too big angle.

After some vain changes to the constants, that only made the robot spin, we thought that we could have done much better by making the robot rotate its "head".

We attached the third motor on the top of the model, with the ultrasonic sensor on it, and wrote an algorithm to make it avoid obstacles while following the wall.
Our code simply made the robot always look toward the wall, and every second rotate the head, sample the distance ahead, and then rotate it back.

After many tries, we decided that the rotation of the head was not enough precise to make the head return in the previous position, so we later made the whole model rotate, and not only its head, to avoid the synchronization problem.

Another variation on the algorithm was to make the robot decide, every time it looked around, what was the position in which it was the most parallel to the wall, by choosing the one in which it sampled the shortest distance to it.
<<youtube video coming soon>>

The only problem left was that when the robot came across a corner and it didn't see any obstacle, it started spinning around.
We then chose to made the robot describe an arc until it founds something again. To make it be an arc of a circle and not of a spiral, we calculated the speeds of the two wheels, as a function of the expected distance from the wall and the (constant) distance between the two wheels.

Since it was too late, and we were almost satisfied of our work, we forgot writing the lab report (and this is why we're writing it nearly a week later), and after having found someone with the key to open the gate, we went home.

NXT Programming - Lesson 1

2007-09-06T10:14:00.001-07:00

Date: 2007.08.06
Duration of activity: 4+ hours
Group members participating: Alessandro, Daniela, Samuele

This time we brought our CDs so we could start to program the NXT brick.
We took up our laptop and started following the installation guides.

Two hours later we were sure that there is no way to install the whole stuff on Windows Vista, so we decided to move to one of the PCs of the labs - now freed up by our course mates gone to home.

We then installed and set up Eclipse, to make it compile and transfer programs.
Of course nothing works, at first because of Eclipse weird behaviour, then because sensors were obviously attached to the wrong port, and at last in finding the little and well hidden button under the USB port.

At 18.44, we have our first moving robot (with only the sample program inside)

Then we tried some modifications to the code:

We changed the sampling speed, which had nearly no effect.

We increased the speed, but not to much, to avoid big swings.

We implemented the three states controller, which obviously could not work with the LineFollower environment (but we were starting to get too tired to noticed it before trying).

We finally implemented the gentle turn, which actually worked better, at least for the black lines that we used.

And since the sun went down while trying, we even experienced how sensors are influenced by the changes of ambient light.

At the end, we just kept playing with lego bricks, and trying some other sensors or model designs without success. We'll be more lucky next time.

Quote of the day:
(While dictating a PIN code)
- "5... 5... 2..."
- "Uppercase or lowercase?"

NXT Programming - prelesson

2007-09-04T18:04:00.000-07:00

We opened the two boxes ("Hooray!"), and started to get confused with the pieces.
So the first thing was sorting pieces in those small compartments.
While sorting, because of our impatience, we also started to build the car model described in the manual.
After about one hour we ended up with the complete first stage of the model, and all pieces were in their right place.
We forgot CDs and battery adapter at home, so we couldn't proceed and went home sadly *SIGH*.