Mission evaluation and source code

Looking back on the final mars mission, we as a group can say that we were quite pleased with the results. Even though the edge detection did not prove sufficient in the end, despite having tweaked it extensively, the mission itself can be regarded as quite a success, as all four modes of our program have been used succesfully.

In the video the modes can be seen clearly: The robot started off in roaming mode, until the camera spotted the lake. When this happened, the robot stopped for a few seconds, after which it started approaching the lake. Measuring the lake and sending the temperature worked succesfully (hence the small applause), after which the robot chose to pass the lake on the right side. Having succesfully done this, the roaming mode was resumed again. Unfortunately, this is where the edge-detection started malfunctioning, ending the mission.

The source code used in this setup, both in c-format and in a very readable pdf-format, can be obtained from http://www.student.tue.nl/p/r.p.j.jacobs/emc_group2.zip

Approaching, measuring and then driving away

Today is matchday, our marslander is capable of succesfully finding lakes and driving away from them. We made a video of the marslander doing exactly this.

In this video our marslander starts of in roaming mode a lake is detected by the camera almost instantly. Hence it goes straight to the lake approaching mode. Once the middle light sensor detects the lake, it’s gets a measurement from the lake. It then proceeds to send the temperature value to the computer (22 degrees in this case). Then it proceeds by driving a away from the lake and returns to roaming after a while.

Mars Mission: Program Architecture

The general architecture of the program of the robot is shown schematically in the following picture.

As can be seen, the program is distributed over two RCX-bricks. In general, RCX 2 will handle everything that involves changing lighting conditions on mars, whereas RCX 1 will take care of the other mission details, using the processed lighting information from RCX 2.

More specifically, RCX 1 is divided into several parallel running threads, each handling a different task. Two major threads include a steering thread and a motion thread. The steering thread simply keeps track of the steering angle, and updates the angle when a request hereto has been made. The motion thread makes use of this steering thread in order to move the robot around on mars. As also stated in the general strategy, the way of moving around on mars is divided into four separate tasks, for which the motion thread has separate running modes. The switching between these modes happens quite naturally at the end of each mode (i.e. switch to measurement when the lake has been approached, switch to roaming when the robot has cleared away from the lake) except for one situation. In order for the robot to switch from roaming to approaching, two separate threads have been created: asking coordinates and receiving coordinates of a detected lake. When roaming, the robot queries earth for these coordinates (which in turn, earth got from the camera). When these coordinates are provided to the robot, the switch to approaching mode will be made. In the lake approaching mode, these threads are used to provide steering feedback.

RCX 2 will be used solely for the measuring and registering of lighting conditions on mars. Since the landscape is quite subject to changing lighting conditions, a static threshold for edge and lake detection is bound to fail. In order to cope with this, RCX 2 will keep track of the history of light sensor values, so that a more robust (in fact, a very robust) edge detection algorithm can be used. Since the three light sensors of the robot arent identical in their measuring capabilities, RCX 2 uses three separate threads to keep track of the lighting history of each sensor individually. Only when an edge or lake has been detected, will RCX 2 send information to RCX 1, so that a minimum of CPU usage due to communication can be achieved.

Mars Mission: Driving away from a lake

Our objective is to measure all three lakes, once a lake is measured you can’t just drive over it.  You risk getting a wheel trapped and getting stuck: an evasive action is necessary. You also can’t just drive back and return to roaming mode, this way you will risk detecting the same lake over and over again.

However, no lake is the same and you can only pass a lake at one side. To take this into account we wrote a program which makes an intelligent choice on what side to go past and make sure it clears the lake safely. Now the driving away is shown schematically in the pictures below, to see a bigger, more readable version you can click the pictures.

The marslander can either try going left or right to pass a lake. There is a chance that even with a good decision (in this case going right) a sensor (in this case: left) goes over the lake again, making it unsafe to drive on. To make sure it clears the lake the marslander: stops and backs up, steers left, then goes forward steering right, as can be seen in the above picture. We know we passed a lake if the sensors detect nothing for a certain time whilst driving away from the lake. Once we passed the lake, we return to roaming mode.

How does one choose the side to go? We decide to try and make a intelligent choice based on a history of sensor information. We count the number of times the left and right sensors are triggered during roaming to determine which way around our marslander is travelling on mars. If the left sensor is triggered the most, then we are travelling clockwise(see video in the post:roaming). This also holds true for the other way around.

Now we know which we around we are going, we know that most land is on the is on the side least triggered. In the case of a clockwise motion: the right. So our marslander will allways try going right first in this case. However it still is possible for our marslander to make a bad decision, we need to take this into account too. The action taken on a bad decision is shown schematiccaly below:

How do we tell we made a good or bad decision? We know there is not enough space between the lake and the edge on one side to go past. We determine if we chose the correct side by counting how long it’s been since our marslander has driven not detected any edges/lakes. If it detects something within this time frame(with the sensor furthest from the lake, in this case the left), we know we made the wrong choice, if it doesn’t we safely passed the lake and return to roaming mode. If we made the wrong choice we back up from the lake and try driving past the other side.

*A video of this in action will be posted soon!

Mars Mission: Roaming

In order to find lakes when the camera can’t find any the marslander should move around mars, this is called roaming. It basically drives around and makes decisions based on light sensor readings. This can be seen in figure above. Using a fixed treshold for avoiding edges and lakes, like we did in the line tracking competition, does not suffice for the mars landscape. The sensor readings are different all around mars, due to the changing lighting and surface.

In order to still effectively use the light sensors a history of adjustable (limited) length is stored with readings of the landscape. This history is averaged out and new readings are compared with the average. Then if the values are significantly different for a number of consecutive times an edge or a lake is detected.  This allows for the marslander to cope with the changing conditions.

Once an edge is detected the marslander will drive back a bit, then drive forward whilst steering in a appropriate direction (i.e. decided on which sensor is ‘triggered’). Then after a while it steers straight and continues to drive until a new edge is detected. This way is it ‘roams’ mars. A slightly exaggerated version is shown in the above figure and below a video is shown  of our marslander just roaming around mars in this manner:

Mars Mission: General Strategy

The general approach to finding and measuring the temperature of water on mars is a very simple concept. As can be seen in the figure, after having descended on mars, the robot starts off by simply roaming around. The goal of this roaming mode (details on this in a future post) is to drive around so that the camera gets a good chance of spotting a lake. When this happens, the roaming mode is being exchanged for the lake approaching mode. The obvious result of this lake approaching mode is that the robot will be in such a position that the temperature of the lake can be measured. After having send the temperature information back to earth, the robot will go into a driving away from lake mode. The purpose of this mode is to clear from the present lake, such that the roaming mode can be safely resumed again.

This scheme will be iterated a couple of times (depending on the number of lakes on mars), until the last lake is found and measured.

Mars Mission: Lake Approaching

The above figure illustrates when the lake is detected on the camera. The lake relative coordinate is determined by Matlab on earth computer and this information is sent to the RCX on the robot. Using this information, the robot can be driven towards the lake for performing the temperature measurement. The algorithm for this is illustarted in the following steps:

1. When the lake is detected on the camera, suppose with coordinate (i1,j1), stop the robot from the previous mars exploration routine (roaming).

2. Turn the robot either to left or right according to (i1,j1) position with respect to the reference “band”, and drive forward the robot.

3. When the lake coordinate is within the reference band, drive the robot straight, and also turn left or right to keep the lake coordinate within the band until the middle light sensor of the robot senses the lake.

4. Perform temperature measurement.

Final linetracking set-up

For the final competition we decided to compare different algorithms by testing them repeatedly. Then whichever has the smallest error (after tuning) and is most stable is the one used for the test.  Remy’s two-brick design came out on top with a average error of less than a millimeter. A small demonstration is shown in the video.

A small hardware modification was done to the sensors to increase the sensors’ sensitivity. We came across information that, when on active mode,  the LED shines directly into the receiver part of the light sensor. This can be solved by blocking light from reaching the receiver directly.  (Note the piece of paper in the middle.)

This made the difference between the readings of black and white twice as big, from 15 percent to 30 percent. After that we looked into the dsensors.h file to see how the scaled value LIGHT was defined. We found this

#define LIGHT(a) (147 - ds_scale(a)/7)

This basically states that the scaled value is then divided by 7, effectively decreasing the resolution by a factor 7! We defined a new scaled value in our own programs by basically multiplying the entire rule by 7:

#define LGHT(a) (1029- ds_scale(a))

Now we have an improved sensitivity and resolution.  With this we are less sensitive to disturbances.

We ended up finishing third in the race!

Lancheng’s Design + video

1brick1

Reyhan’s design + video

For the line tracking competition, there could be several possible hardware and software designs to achieve the goal. Above is a hardware configuration as well as a brief description of the task of each brick, proposed by Reyhan. The demonstration of the design can be seen in the following video:

Performance improvement is absolutely necessary for this design. Either by improving the steering method or length measurement algorithm. If there is not much improvement by doing so, the total hardware & software design may have to be modified.