#1 !! And the real winners are...

Today, on June the 16th, we have managed to ALSO win the Mars Mission!
Although this was certainly not one of our best runs; As we never experienced before while testing, the Rover didn't move anymore halfway the mission and seemed to be in some kind of deadlock. But after a quick restart, the rover could continue and measure the lake again (although it was the same lake).
Another thing that went wrong was that the first lake measurement was not actually in the lake. The temperature sensor missed the lake a bit and hit the ground.

But we could give a short representation of our code and convince the jury. The Rover managed to receive coordinates from Earth multiple times, drive to it and measure a lake 2 times (although it was the same lake). Both lake-temperatures were sent succesfully to Earth. Furthermore, we could give a nice impression of our smart lake finding stategy (the 'random drive' mode) and showed that we had a robust edge detection by not falling of an edge.

As said before, our Mission today was not a very good mission, but we still outperformed the other groups.
The best mission of our Rover is visualized in the movie on June the 14th, where all the lakes where found and 2 of them where measured correctly.

The Mars Mission

Today is the final day before the Mars Mission.

Although it is not smart to adjust the code the day before the actual mission, we tried to improve some minor things in the code.

Of course, the 'working' code from yesterday is kept, so we can also fall back on the working code.

For example, the Rover only used the left and right light sensor for edge detection.

If the Rover misses a lake (due to crappy video detection or due to driving over a lake that is already measured), the middle lights sensor is not used and thus the Rover could get stuck in a lake. (Although it can recover from driving inside a lake sometimes, this does not always work due to the extra weight of the batteries). This was still one of the problems that is not handled correctly by our program.

Now the code is adapted in such a way that the middle light sensor is also used for edge detection only IF the Rover is not close to a lake. Close to a lake, the middle light sensor is used for lake detection. This is also tested extensively on a 'table' with fake lakes.

Another bug that was still pending was that while measuring the lake, the edge detection is not 'stopped' correctly. If there was a sudden trigger in the left or right light sensor, the Rover just started driving backwards 'avoiding' the edge while the temperature sensor was still in the lake. This results in a broken Rover. Although we did not encounter this problem while testing, it is a risk. If for example somebody walks past the Rover and his shadow triggers a light sensor, the Mission is lost.

The code is also adapted such that this bug is removed. This modification is again tested extensively on a 'table' with fake lakes.

After the code seemed to work fine again, we asked if we could borrow the camera for 10 minutes to do some actual testing on Mars. Below a short movie is indicating that the Rover seems to work properly. However, there was not enough test time so we could not finish the Mission and do much more tests. Again the main problem was the detection of the lakes, which is really crappy.

The BEST Mission is still visible in the movie of yesterday, so please see that one also.

The adjustments to the code seemed to work properly, so we decided to use this last code for the final Mission tomorrow.

Now we will give the exact details and strategy of our code for the Mars Mission. The main idea is already discussed in the presentation.

The goal of the course is to find all the three the lake, measure the temperatures and send the temperatures to Earth. While doing so, the Rover should not fall off the Surface or falls into a lake.

First the hardware configuration setup for the different bricks:

RCX 1 : left + right light sensor , 1 encoder , motor left, motor right

RCX 2: middle light sensor, temperature sensor, motor temperature-crane. (second encoder is not used)

The different tasks on the different bricks (Note that the bold tasks are always active and running in parallel).

RCX 1:

- Read_from_ir (receive information from RCX 2)

- Received (store valid coordinates)

- Edge (edge detection and avoidance)

- Rand_drive (smart random driving)

- Drive2lake (drive to a lake via calculated path, receive/send lake information to/from RCX 2, avoid lake after measurement)

RCX 2:

- Read_from_ir (receive information from RCX 1)

- Send_to_ir (send temperature to Earth)

- Lake (detect a lake, or probably a cliff with the middle light sensor and send info to RCX 1)

- Measure (If no edge is found, this function is initiated and the temperature is measured. After this, the temperature is send to RCX 1 so the Rover knows it can start avoiding the lake and continue the mission)

Now our strategy:

The main thought is 'Safety First'. This means that the RCX 1 brick that is used for actuation of the motors is also used for edge detection. By doing this, the response time when an edge is found is minimized and the Rover can also stay safe if IR communication fails.

As an extra, the middle light sensor is also used for edge detection if the Rover is not close to a detected lake (detected by the camera).

Edge detection:

For edge detection, the left, right (and middle) light sensors are used. To read out the light values, we used the raw data (as we did with the line tracking contest). This means that the resolution of the light values is increased. For a standard light value, the brick gives values round 50, when the raw data is used this value is round the 700! The information for this raw data can be found in the 'C API'. The only thing that has to be used is the 'ds_scale()' function.

Edge detection itself uses the gradient of the light values. So if the difference between the current measured light value and the previous stored light value is deviating more than a certain value, an edge is detected. Then all the other tasks must stop and the edge avoiding algorithm is started. The Rover always drives backwards for a certain distance and then turns to the intended direction. If the left light sensor detects a cliff, the Rover turns to the right. If the right light sensor detects a cliff, the Rover turns to the left. I this way the Rover always continues in the direction it was driving. If however, both the left and the right light sensors, of also the middle light sensor detects a lake, the Rover is facing a cliff (almost) straight. We chose to drive the Mars landscape in a counter-clockwise direction as a 'standard' direction, so in the last case the Rover will always turn to the left.

If the Rover detects an edge during driving to a lake, we assume the lake was a 'fake' lake and the current stored coordinates are erased.

The middle sensor is only used for lake detection when valid coordinates 'close' to a lake are received. 'Close' to a lake means when the received 'i' coordinates are smaller than a certain value.

When these coordinates are received, first the Rover turns until it is facing the lake directly in the middle (according to the received coordinates). It then starts driving until the middle light sensor is triggered. When RCX 1 received this trigger, the Rover stops and looks with the other two light sensors if the Rover is still on the Mars Surface or if it is past an edge ( this can happen when false lakes are detected by the video processing in for example the DCT lab). If no edge is detected, the RCX 1 sends a message that the RCX 2 can start a measurement.

Asking coordinates from Earth and the sending temperature:

RCX 2 don't have many tasks while roaming over Mars (While RCX 1 has). This is the main reason why we chose to let RCX 2 continuously (every 300 ms) send the temperature of the last lake to Earth. If no lake is measured yet, the value 0 is send to the Earth station. By doing this, we smartly both send the temperature to Earth and ask for coordinates from the Earth computer continuously (every 300 ms).

Receive coordinates from Earth:

It is always possible for RCX 1 to receive valid coordinates. If for a longer time (officially it is a number of counts with invalid coordinates) no valid coordinates are received, the

'Random Drive' sequence is started. This 'Random Drive' sequence is directly stopped if a valid coordinate is received. If a valid coordinate is received, this coordinate is stored and the 'Drive2lake' sequence is started. While the 'Drive2lake' sequence is busy with turning and driving, no new coordinate information is used.

Only the coordinates of the first lake are used. Due to the 'crappy' lake detection (probably due to the combination of light intensity, camera and video processing algorithm) a real second lake is never detected simultaneously. This is also the reason that we don't use the information of other detected lakes further away.

Driving to and Measuring a lake:

The 'Drive2lake' sequence first converts the camera coordinates into world coordinates using a polar coordinate system. From the 'j'th coordinate, the number of encoder counts the Rover should turn to position the Rover straight to the lake is computed. Then this calculated turn is made.

From the 'i'th coordinate, the distance to the lake is calculated. If the rover is 'far' way, the rover first drives closer to the lake for such a distance that the camera can still detect the lake and asks new coordinates for repositioning. When it has received new coordinates, it can adjust its turn angle once more and then drives directly to the lake until it receives the trigger from the middle light sensor on RCX 2 (RCX 2 sends this trigger 2 times, so if the first transmission is missed, there are no problems) and then the Rover stops and sends a trigger to RCX 2 (also this trigger is send 2 times in order to prevent deadlock) if it is safe to start a measurement.

RCX 2 then performs a measurement by lowering the temperature sensor and waits for 5 seconds before the temperature is measured. The temperature is measured in degrees Celsius and is specially calibrated. When the sensor is moved back up to a safe position, RCX 2 sends the temperature to RCX 1 (again the temperature is send 2 times). When RCX 1 receives the temperature, it knows that the measurement was a success and it is going to avoid a lake by driving backwards for a certain distance and then turn to the left. Knowing the Mars Surface, a turn to the left with counter-clockwise driving was the best option. Smarter lake avoiding is not implemented due to a lack of time. Of course, the RCX 2 continues to send the temperature to Earth.

Searching a lake smartly:

The 'Random Drive' sequence starts if no coordinates are received for a while. We programmed this program smartly by letting the Rover turn every now and then to see if a lake is nearby. This turn angle is optimized such that over the complete turn the total field of view of the camera is approximately 180 degrees. At every turning endpoint, the Rover stops for a while so the camera processing and IR communication has its time to send detect a lake and send coordinates to the Rover. Then the Rover turns back to the direction it was heading previously and drives forward for a certain distance. Now the procedure is started over again.

When an edge or a lake is found, this task is stopped and edge avoidance / drive2lake is started.

After the edge avoidance / lake measurement, the 'Random Drive' sequence is started again if no new lake coordinates are received again.

Stopping when 3 lakes are found:

Every time a lake is measured and a temperature is send to RCX 1 (and Earth), a lake is counted. We programmed that the Rover BEEPS and displays 'END' on the LCD-screen when 3 lakes are measured and then all the tasks are killed.

Shortly, the Rover thus does the following:

When the Rover is initiated, It first looks for valid incoming coordinates. When coordinates are received it drives to a lake, measures it and resumes the Mars Mission until 3 lakes are found. If in the meanwhile no coordinates are received, the smart random drive sequence is used to detect lakes efficiently. If an edge is detected during the mission, safety goes first! All the other tasks are stopped and first the edge is avoided.

Now there are still some things to mention that we encountered during the coding of the program.

• To use our CPU resources efficiently, we first thought of also killing the communication threads during the measurement of a lake and during edge avoidance (then no coordinates are needed). However, when re-initiating these communication threads, the brick crashes every time.
  The solutions was to never kill the communication threads
• Although we did not kill and reinitialize communication threads, other threads where killed and re-initialized in for example the edge detect and avoidance thread. However, the brick crashed sometimes for a vague reason and sometimes not at the same point. We thought that maybe the memory is not cleaned entirely when a thread is killed and thus eventually the brick has not enough resources to start the thread again.
  We solved this by using main files on both bricks without killing and reinitializing at all. However, now we had some problems with correct starting and ending of different threads wanting to simultaneously use the motors. But this is solved now.
• The use of different priorities for different threads did not work, because it constantly tries to start the tread with the highest priority and don't bothers about the other threads.
• With this 4 wheel design with 'slipping' wheels on the back while turning, the Rover can get stuck if a rough surface on Mars is encountered during turning. We programmed this turning on a number of counts, so if it is stuck, the Rover is lost.
  We solved this by inserting a counter/time. If the turning takes too much time, the turn is ended and the program/Rover continues.
• THIS IS OUR BIGGEST PROBLEM: The detection of a lake!
  We only use the camera to detect lakes (as was intended). If no lake is found with the camera, always an edge is assumed for safety precautions.
  Probably the combination of the camera, the light intensity, the water in the lakes and the video processing algorithm (or only one of them) gives the problem that almost no lake is detected and thus sent to the Rover.
  We already encountered that at a high light intensity of the lamps above the surface, it is harder for the camera to detect lakes.
  The lakes are also better detectable when there is no water in the lakes (disturbing the blue color).
  Furthermore, the camera and/or video processing could use an update, because even close (and directly facing) to the lake, most of the time no lakes are detected.
  We can't do anything about this, but this will be probably the deciding factor for a successful Mars Mission tomorrow.

We did some extra checks like checking (and replacing) the batteries, erase all bricks, put the firmware on it again and only put the final code on the bricks.

We hope we will perform well again tomorrow. As said before, the deciding factor for a successful mission will be the lake detection by the camera!

Real time testing of the (semi-) final code

Today we had our last 2 official test hours before the actual Mars Mission. We made some minor adjustmunts to the code.
For example, we first had some problems with the Rover getting stuck while turning in the random drive mode due to the rough surface. Because the encoder then does not count anything in that case, the motor kept running for eternity, because the Rover is not moving. Now the 'random drive' will stop if after a while the counts are not met, so the Rover can continue. We also tried an extra burst to let the Rover come loose again, but this can be too dangerous near an edge.
Another bug was that sometimes the Rover wanted to measure the lake twice before proceeding, this bug is also fixed now.

We tried several test runs today and made some adjustments while testing. The resulting best Mars Mission is depicted in the video below:
In this Mission all the 3 lakes are found, but only 2 are measured and transmitted to Earth correctly.
The Rover starts and directly finds the first lake. It then turns towards it and drives closer. When it is closer, it again recheives coordinates and adjusts the turn-angle once more before it drives to the first lake. The Rover stops in time and measures a temperature of 22 degrees Celcius. After the temperature measurement, the Rover advoids the lake and goes into 'random drive' mode. It then turns left and right is such a way that a field on vision of 180 degrees is obtained. Note that the Rover stops at the maximum turn-angles and does regular stops, so the video processing has enough time to detect lakes.
When the Rover has found the second lake, it first drives closer to the lake. When it is close, the Rover turns and starts driving towards the lake untill the middle lightsensor detects the lake. However, the middle lightsensor already triggers a too big change and thinks the lake is there already (before the actual lake is reached). This results in a fake second measurement.
But the Rover again 'avoids' the 'lake' and starts to drive 'randomly' as we programmed. In the meanwhile, the Rover detects an edge and adjusts for it as we designed (drive a little bit backwards and then turn to the right direction, which is in this case turning right).
Then it again starts the random drive sequence (because still no coordinates are received) untill it finds the last lake. This lake is again measured perfectly, resulting in a temperature of 21 degrees Celsius.
The Rover now thinks it has measured 3 lakes, so it BEEPS and 'END' is displayed on the lcd screen of RCX 1. The mission was a (partial) succes!

Our Rover still does not perform perfectly and still some small bugs are in the program. However, (testing) time is limited, there are a lot of groups and the deadline is tight. We will possibly try to adjust some minor things tomorrow (the day before the real mission) and off course we will test this. (If we can borrow some time from other groups).
However, we assume that we now have our (semi-) final code, because more testing and debugging is almost impossible.

Hopefully we will perform well in the actual mission, as we did at the linetracking contest!

And the winner is...

Today, on June the 10th, we have managed to win the Chess Line Tracking Competetion!
Beforehand we were quite confident of ending in the top 3 of best line trackers. The last couple weeks our line tracker performed well with all sorts of tape and surfaces; it could measure the line with 1 mm accuracy every time. However, today before the competition, somehow we could only measure the line with 4 mm accuracy. We could not find an explanation for it, but we have listened to the advice of Marcel Verhoef: do not change your code just before the competition. With fingers crossed we saw our line tracker ending up first with an error of 4 mm (as we already expected), because the only group that outperformed us did not code beeps at start and end. We have measured 735 mm, while the true length was 739 mm.

So the first prize, one crate of beer, was ours to keep. Cheers!

This is a good start towards the Mars mission next week, let's hope we can perform like true winners...

P.S. the presentation can be found here: http://www.student.tue.nl/V/a.bos/EMCfajl.ppt

Chess Line-Tracking Competition

Because tomorrow the final Chess Line-tracking competition will start, it is time for us to reveal our strategy for the line-tracking.

We have held the exact details of our code and strategy secret to make sure other teams do not copy our ideas. We do the same with our Mars Mission. Tomorrow in the presentation most of our ideas will be showed, but also just before the Final Mars Mission we will update our blog with our strategy and code for the Mission.

The first idea for the line tracking is to keep things as simple and effective as possible. This is the reason that we chose for one RCX brick. On this brick we use the following things:

RCX 1:   Light sensor 1      Determine the start and the end of the line and reject cracks on the way.

              Light sensor 2      Track the edge of the line with a PD controller

              Encoder 1            To measure the distance of the tape

              Motor 1               Drive the left front wheel

              Motor 2               Drive the right front wheel

This idea is also visualized in the figure below. The tape detection light sensor is placed a little bit up front to the PD line following light sensor in order to find upcoming disturbances, cracks and of course the beginning and the end of the tape.

First the rover is placed at the beginning of the tape and started. It then calibrates the light values of the tape for both the sensors (because the sensors are not the same). It then drives backwards and calibrates the light values of the surface for both sensors. Note that we read out the raw data of the light sensors, so we have a better resolution which will give us an advantage in tracking the line and to be more robust. After this, the Rover drives towards the tape and stops when the beginning of the line is detected. It then BEEPS and starts the tracking.

The first light sensor tracks the line and when a crack with a too high variation from the original tape light value (this can be both a lighter or a darker disturbance on the tape) or the end of the tape is detected, the PD controller will be shut down for a certain time and the Rover drives straight until again the tape is found. If it takes too long before a tape is found, the Rover assumes it was the end of the tape, stops driving, BEEPS again and displays the length of the tape in [mm] on the screen.

The second light sensor tracks the EDGE of the tape (and thus the transition between the tape and the surface) with a PD controller. In this way the line can be tracked very smooth and precise. The P action makes sure it tracks the edge of the line by letting the Rover make small corrections on the speed of the motors. The D action is used to correct errors that ‘haven’t even occurred yet’ and thus to let the Rover drive smoother. In our first implementation we also used an I action (PID controller) to let the error go to zero. But we know we only have to drive a ‘straight’ line and because the distance measurement is very important, we preferred the smoother PD controller.

Another very nice thing about this PD controller is that we scaled the error such that the PD controller is tuned the same for every possible tape and surface.

To have an accurate measurement of the length of the tape in [mm], it was demanded to have at least a resolution of 1 [mm/ encoder increment]. We made a special gearbox with a different transmission ratio form the motor to the wheels to acquire a certain amount of torque and speed and a ‘different’ transmission ratio from the wheels to the encoder. A transmission ratio of 0.948413 [mm/encoder increment] is achieved with this method, giving very accurate measurements of the line.

Even better would be to also use the second encoder, so we can average the length of both encoders in case there is a lot of curvature in the line. To implement this, a second RCX brick is needed together with communication. Because of the tight schedule for the Mars Mission and a Line-tracking design that is already satisfying our requirements, we decided to put our (limited) time and energy into more important things.

A last movie of the line tracking is depicted below. We have a lot of confidence that our Line-tracking Rover will perform well and hopefully finish in the top 3 at least.

Putting it all together, part 2

Today we started where we left off yesterday: Trying to let all the functions work together. After a lot of attempts and some strange problems with IR communcation between bricks with codes that where just working fine yesterday (a simple firmware update solved the problem eventually), we thought of a way of changing the starting and killing of threads. The code now seems to works without crashing and most of the problems are solved, but now it seems that at the point of switching between two different threads the motors sometimes behave a little bit strange. We need to figure this out in the next days.

After a while we had the opportunity to use the camera for a moment and try to test our code on the real Mars Surface. The first thing that attracted our attention was that the right 'building-lamp' above the Surface was shining much brighter than yesterday and the days before. We think that the bulb is changed.
The problem now is that the camera (together with the software) almost can't detect lakes anymore. While yesterday 2 lakes could be detected easily and 1 was hard to detect, today only 1 lake was detectable, and it was much harder than the other days. I also heard the group before us complain about the same thing: For some reason also they had trouble detecting lakes today.
I hope this will be changed, otherwise I think the real Mars Mission next week will be a disaster for most of the groups, due to the crappy lake detection by the 'blazing' light.
We also found out that the gradient values we use for the lake detection on the middle lightsensor now must be adapted. Due to the new lamp also this value has changed.

The only testrun we had is displayed below: We made a test on the lake that was just detectable. First it does not see the lake and starts the 'random drive' mode. After a while it recheives coordinates and start to turn and drive to the lake. As I said before, the gradient of the lake detection has changed, so now it thinks there is a lake just in front of the true lake. Probably due to the combination of the shadow of the rover and the new shining lamp. We had no chance to correct it today, but that will be done later.
After the lake is measured, the rover avoids the lake and the cliff and drives further away up to the possible next lake (which can not be found)

Putting it all together, part 1

Today the starting of the random drive is modified al little bit. Now it does not starts after a certain time, but after a certain amount of receiving non-valid coordinates.
Furthermore, most of the implementation problems are gone now. Random drive starts and drives smoothly together with edge avoidance. Also, when a lake is found, it drives towards the lake and measures it.
The lake avoidance is new: after RCX 1 receives the temperature from RCX 2, it starts to drive back and turn and remebers that it already measured one lake. Then the random drive or cliff detection can take over again. The problem we have now, is that after measuring a lake, when the robot is in random drive mode and tries to avoid an edge, the program crashes and the whole RCX block must be updated again.
This is probably due to using to much resources of the bricks memory/cpu, because the problem does not occur before a lake is measured.
It is very hard to find the problem and make sure that it will not happen again, but when this problem is finished, the core program with the core elements is finished and the improvement of minor things, the testing and debugging can start.

Finding a lake and also measuring it

After spending a whole weekend on finding the communcation problem and errors in the file, eventually a new code is build from scratch. Every time a new function is introduced and tested untill it works fine, while RCX 2 is playing as the Earth Station and sends the coordinates.
Today the code is used on the real Mars Surface and some minor things were not working on first hand.
Eventually the code already contained the receiving of the coordinates, the sending of the coordinates, the edge detection (and avoiding) and of course the driving to the lake.
This driving to the lake function is new and currently it works like this:
It stores valid coordinates, turns until the lake is in the middle and calculates the distance to drive to the lake.
Close to the lake it again turns to the middle of the lake (because there can be a deviation due to different motor speeds) and drives until the lake is found.
To detect if a lake is found, the second brick RCX 2 needs to send to RCX 1 that the lake is found. Then the RCX 1 detects if it actually is a lake, or if it is a cliff (the other ligth sensors may detect a cliff), and sends to RCX 2 that it can start measuring the temperature. After the temperature is measured, the temperature is send to the Earth Station.

Below we see 2 examples from this code, the first one is from a close distance where it directly drives to the lake, the second is at a different lake at a longer distance, where it also corrects to the middle of the lake twice.

We also started to implement the 'random drive' function in the working code above, but it does not work the way we want yet.

The next thing to do is to implement the random drive correctly and also think about avoiding the lake after it is measured.

After that, the most important things in the code are made and some tweaking is necessary. The distance calcuation to the lake can be improved and also the edge detection should be tested more thoroughly.

Time to speed things up

Last Wednesday we have tried to test a larg amount of code; it was supposed to find lakes with the camera, receive the coordinates and drive to the lakes. Also cliff detection (and rejection) was part of it. Unfortunatly, we had communication problems. Sending information and cliff detection worked fine, but receiving coordinates was a problem. Receiving coordinates from the earth computer without other code seemed to work just fine, but the same code with other threads running in parallel seemed te give rise to problems.

In the meantime we have thought about smart roaming/random driving when no lake is found. We have implemented it with cliff detection (and rejection) as can be seen in the video below. The Mars Rover drives straight and then looks for lakes in the neigbourhood, if it doesn't find any it continues driving.

Threads and communication

In this test both bricks are used. We wanted to gain more insight in the situation where multiple threads are running at the same time and the brick has to communicate. The tasks are divided over the 2 bricks as follows.
* Brick 1:
   - Thread  for cliff detection and avoiding them (for now only the right light sensor)
   - Thread for stopping at a lake (middle light sensor)
   - Communication with brick 2
* Brick 2:
   - Performing an experiment after receiving data from brick 1 that the rover is at a lake.
This way multiple tasks are integrated and tested. Unfortunately we couldn't test the program at the Mars setup, so we had to perform this test at the edge of the table. When the right light sensor measures the edge its a cliff and when the middle light sensor measures the edge its a lake. As can be seen, the program works well.
Later on the sensors and actuators are divided differently over the 2 bricks, but for now we wanted to understand this type of situation.

Lake driving and measuring, Line-following almost completed

Today we did some work on driving to a lake when coordinates are received and positioning in front of it. This code is not fully operational yet, but we are still working on it.

Furthermore, the part of the code that measures the temperature of the lake is completed. When the middle sensor detects a lake, the temperature sensor is lowered into the lake and the temperature is measured and sent to the earth computer. This can be seen in the movie below:

Also, we have almost finished the line-following code. Besides testing in the actual room where the line following is held and making some minor changes to the code when needed, we have completed the code to everyone's satisfaction.

Line-tracking progress

Today the line-tracking programm is updated again. The controller is replaced by a PD controller. After callibration, the error in the program gets scaled according to the calibrated values so that the PD controller doesn't have to be tuned again for every new condition.
The program is also made more robust for cracks and deviations in the line. Another addition is that with the same program, it can follow dark lines on light surfaces or vice versa!
Tracking a black line on the table surface:

 

 Tracking a light line (the table) on a dark surface. Note that it starts on a piece of tape and thus sees this tape as the surface and the table as a line:

Temperature and Threads

Today we have calibrated the temperature sensor's raw values to actual degrees in Celsius. We have also managed to send the temperature to the Earth computer.

Furthermore we have experimented a bit with the use of threads. Threads are going to be very important in making the MER doing the tasks he has to perform.

We have also worked on the code to make the MER drive to a lake when the coordinates are known.

More on all this later...

Roaming on Mars with Edge and lake avoiding

Today the Rover had his first roaming on Mars with edge detection and lake avoiding turned on. The video below gives a nice impression of the roaming, it even can get out of a lake.

When looking at the image processing and lake detection, the lake detection (due to image processing) is not working as desired. Sometimes the lake detection is very poor and even when the Rover almost stands in front of it, the lake is not detected.
The strategy to use the vision and the received coordinates as real time input for driving to the lake is likely to fail. We now must think about another idea for this task.

Sometimes a lot of lakes are found as shown below :)

Robust line tracking

Now the line tracking algorithm is made more robust and complete as can be seen in the video below.
After the calibration, the Rover first searches the tape, when it has found some tape it stops, makes a sound and then start driving. After the tape stops, it again makes a sound and then displays the length of the line (in mm) on the lcd-screen.
The controller still needs some tuning for a smoother tracking, but it is already a little bit robust for line cracks and other variations.
The main goal now is to tune the controller correctly and also let it work for different tapes and surfaces (for example a black surface and white tape).

Building of the four wheeled Mars Rover

The building of the four-wheeled Mars Rover seems finished for now on; It now can also hold the two RCX bricks and the camera. A picture is displayed below:

After some tweaking the camera is positioned in such a way that it can detect lakes up to close and from a nice distance. Also a picture of the detection of a lake is given below. The lake is coloured purple in the lake detection program.

Contact with the Earth Computer

Today we have established our first contact with the Earth Computer from Mars.
The coordinates of the lakes are transferred and displayed at the screen of the brick.
When the brick asks for coordinates, it displays 'ask'. It displays 'coor' when coordinate are rechieved and then it first prints the 'i' coordinate and then the 'j' coordinate.
This directly gives us a good insight in the use of different tasks and the parallel use of it.

Distance measurement while tracking a line

Tracking a line has advanced to the next stage, as the distance travelled can be measured in mm.

A movie of line tracking with distance measuring is given below, where first the light sensor is calibrated to the environment and the line (crack in this case) followed by the MER following the line (with untuned PID-control) for a couple of loop-iterations until it stops and writes the travelled distance to the LCD display of the Lego brick. It has travelled 613 mm in this case.

The MER transmission is adapted to a pleasing cruising speed when following a line, as well as a nice gear ratio for the rotation sensors. The transfer ratio from the wheels to the encoder is 50/3, while the circumference of the wheel is (about) 257.6 mm. This results in a resolution of around the 1 mm/encoder count  (0.966 mm/count to be precise).
In this way, the distance travelled can be given to a millimeter, as is required in the line tracking competition.

In the movie above, we used two motors, one light sensor and one encoder.
At this moment, we are planning to use only one Lego brick for the line tracking competition. In this way, we make everything as simple as possible, but not simpler.
We are programming to use two motors to drive the wheels, two light sensors and one encoder to do the job. One light sensor should take care of the straight line PID tracking, while the other one (in combination with the first) should detect the beginning, ending and possible interuptions of the line without problems. The encoder is used to measure the length of the line to a millimeter.

First Line-tracking 'steps'

Our Rover has tracked his first line, using a PID controller. This controller will be made more robust in the future and the measuring of the distance of the line will be implemented also.

IR Communication between RCX bricks

Today we established the first IR communication between the two RCX bricks (also using threads in the C-code).
In the video below, the left brick sends an integer (and displays it on the screen) and then adds 10 to it, the right brick receives the integer and also displays it on the lcd screen.

Testing of the four-wheeled MER

Today building the four-wheeled MER advanced even more and we tested it's capabilities.
Using a test-program, the MER drives straight until it discovers an edge and then lowers and raises the temperature sensor. After this, the MER drives backwards and continues in another direction.
In the video this test can be seen.

The building of the four-wheeled MER has started

The building of the four-wheeled MER already has started and the temporal result is visualized below:

Now 2 separate motors are used to drive two wheels on each side to make steering easy and fast. The tires are removed from the other (passive) wheels to keep friction to a minimum. Note that after a better inspection, the Mars surface is more even as thought, so a three-wheel design with a caster wheel also seems to be a very good choice. However, this four-wheel design will be used for the moment and when the achieved results in the future are not what we expected, it is easy to change the design without changing the c-code much.
The 'big' wheels are chosen, so a high speed can be achieved. When a lower speed and higher accuracy is demanded, it is possible to reduce the gearbox ratio or even to reduce the wheeldiameter.
The final design will also have a center of gravitiy very close to the two active wheels and not at the passive wheels to keep the friction while steering relatively low.

Component Diagram

Our first concept Component Diagram that can be used with the four wheeled robot is depicted below.
In the diagram different functions that are nedeed are visible and furthermore clearly the division of the sensors and actuators over the blocks are shown. The main idea behind this division is the idea of 'Measurements and driving can be handled separately from eachother'.
Thus the most important sensors (light sensors left + right to detect a cliff) and the most important actuators (motors left + right to move and steer) are used on one RCX block to prevent damage and stay controllable. The other (less important) measurement 'equipment' are used on a different RCX block.

Building-plan MER

This building-plan gives a quick overview of the possible solutions to build the Mars Exploration

Rover (MER). The solution that seems most suited to complete the line-tracking and mars mission is made clear.

Possible issues for the MER are:

• Center of gravity for grip and stability: as low as possible

• Speed: small, light robot but it is easier to miss goals

• Wheels: big wheels will result in more speed, but less power

• Wheelbase: wide as possible to have stable robot and good straight line tracking/driving

• Turning-circle: small to easily turn on the limited space available

Chassis design

A number of chassis designs are possible, each with its advantages and disadvantages. A

couple of properties are given below:

• Three wheels

– two-wheeled robot with caster wheel

– each wheel driven by separate motor

– advantages: small turning-circle, turning easy to program, easy to build

– disadvantages: have to look at center of gravity with building, can be a bit unstable (especially at uneven surfaces)

• Four wheels

– four-wheeled robot, two wheels driven by separate motor, two wheels passive (can

also be four, with four motors)

– advantages: small turning-circle, turning easy to program, stable without problems

center of gravity

– disadvantages: skidding of passive wheels: lot of resistance. Possible solution: no tires on skidding wheels for less resistance

• Six wheels

– six-wheeled robot, two wheels driven by separate motor (center), two wheels steering,

two wheels passive (current design)

– advantages: stable, good for hill-climbing and rough surfaces

– disadvantages: large turning-circle, turning difficult to program, difficult to build, resistance with steering, straight line driving difficult

• Tracked robot

– rubber tracks, four (or six) wheels

– advantages: stable, low center of gravity, good on uneven surfaces and obstacles, can be capable of driving over a lake

– disadvantages: hard time traveling straight line, hop on smooth surface, rubber tension can be difficult (possible solution is to use a wheel in the middle for extra tension), a lot of friction

Steering

There are two possible ways of steering the MER

• Differential steering: compare with a wheelchair, so using two separate driven wheels

with different speeds/powers to steer; fast steering with small turning-circle

• Dual-wheel pivot steering drive system (current design): difficult steering mechanism,

need to calculate angles (with its deviations), furthermore you have to steer and steer

straight again; slow steering with large turning-circle.

Line tracking/Mars mission

For the line tracking we want a good straight-line tracking robot, with good steering properties

and reaction time. Furthermore we need to predict the length of the line as accurate as possible

(this means to zig-zag as less as possible). It is possible to use one light sensor (control on

the ’grey’ area between the line and environment colour), two light sensors (need to know the

width of the line) or three light sensors (same as two light sensors). I assume that the width

of the line is not known on beforehand, so we need to use one light sensor for the line tracking (and maybe one other to detect if the line starts/ends)

The best choice(s) for line-tracking in our opinion is (are):

• Best chassis: Robot with tree wheels (two wheels, separately driven, with a caster wheel).

A four wheel robot can also be a good choice but as the surface will be even a three-wheeled

robot will can be controlled most accurate

• Best steering: differential steering (wheelchair)

• Positioning light sensor: for following straight line, it is best to place it close to the pivot

point (less zig-zag behaviour). For following arcs it is best to place it far ahead of the

pivot point (current design).

• Check distance traveled: measure circumference of tire + rotation sensor(s)

For the mars mission the current design (six wheels) is not the optimal one. As the surface is

relatively even and pretty compact, a small turning-circle is wanted.

The three-wheeled robot can give stability issues, as the mars surface is not

entirely even. The best choice seems to be the four-wheeled robot. As the mars surface

is pretty rough, we need to check if the resistance with steering is not too big. Differential

steering seems to be the best choice in the small space that is available.

Design choice

As we don’t want to change the chassis for the line-tracking and mars mission, the best choice seems to be the four wheeled robot (two wheels driven by separate motor, two wheels passive). We are going to start building a light,stiff robot with a smart and low center of gravity, using smart and stiff suspensions with little friction and hysteresis to be able to drive straight lines when wanted. Design principle knowledge will be used here.

The light sensors can/will be positioned differently for the line-tracking competition and the mars mission, so they should be easy to (un)mount. We can change the transmission (gear ratio) when more speed (less accuracy!) is wanted.

If the four-wheeled design appears to have too many drawbacks/disadvantages in a later stadium, we can always change the design to a three-wheeled robot or even a tracked robot fairly easy.

Requirements, use case diagram and activity diagram

The requirements, use case diagram and activity diagram for now are given below.

REQUIREMENTS

Most general requirements

·         Detect craters/cliffs                                      M

·         Detect lakes                                                  M

·         Don’t fall into a crater/from a cliff               M

·         Drive to a lake                                               M

·    Position in front of lake                                 M

·         Measure temperature                                   M

·         Don’t fall into a lake                                     S

·         Find all lakes                                                 S

User interaction

·         Display the temperature/Send it to PC         M

·         Victory sound                                                W

Statistics

·         Store the outcomes of the experiment          S

·         Don’t measure a lake twice                          C

Flexibility

·         No area specified (# craters, their positions,..)                         S

·         Fast driving                                                                                W

·         Fast detection of lakes                                                              W

·         Don’t lose a lake from sight                                                       S

USE CASE DIAGRAM
This is the first concept Use Case Diagram

ACTIVITY DIAGRAM
This is the first concept Activity Diagram



Safe driving

Since we were able to read out the light sensors and actuate the motors, we let te mars rover drive on the table and stop when one of the light sensors detects an edge.
On start the display shows: "OK!" and when it detects an edge, it displays "break".

Straight approach:

Alternate approach: