Mission to Mars

We finished our mission/course!

In our first run we had some difficulties with the hardware, our rover was not able to drive backwards. After we repaired the mechanical part we gave it another shot. It turned out that we did not receive any coordinates, so even not 0,0. Thus there was no communication from the earth computer to our rover. This resulted in the zigzag mode, the mode which is performed when there is no communication.

For people who are interested, our code is posted here and the description is in our previous posts. Now we just have to wait for our final mark.

Download code HERE

Marsrover got stucked in sand...

Source: TechnischWeekblad, edition 23, 6th of June 2009, page 1

Strategy Master Brick

The strategy of the master brick determines everything what is going to happen, it runs as a threat with a lower priority then the communication. It executes the primary functions such as driving, measuring the lake temperature and communication. Software The strategy software uses switch cases to put the rover in its correct state. The action to be executed is determined by carefully chosen if and else statements. The statements are triggered by the return statements of the functions used.
The used states are:

• Communicate earth; The Brick communicates with the earth to obtain the coordinates.
• Approach lake; The rover is going to approach the lake with the obtained coordinates.
• Temperature Lake; The temperature of the lake is measured and send to the earth computer.
• Get away; We are finished at the lake so it is bypassed. from the lake after measuring
• Zig Zag; If something does not work properly the rover will start zig-zagging for a certain amount of time and will keep on trying to start again.

Lake Approach Working

Today, we tested the final things of our lego rover. The last and final thing we had to test in the completed code, was the lake approach. We measured some data on the landscape to simulate our own landscape, with the use of our own simulated earth PC. In the video, the black tape at the end of the video, is the lake according to the coordinates on the mars landscape. See the video below for a visual representation.

(turn on your music to hear our team song!)

Final version of our communication software

Since the beginning a lot of work has been done on the communication software, mainly because we build this part of the software from scratch on, meaning no ‘com.c’ or ‘easy’ sending of communicating with earth for coordinates and temperature. This was done so that we could completely understand what we were doing and design the software exactly as we wanted it. Furthermore there are parts in the communication software nowhere to be encountered in the rest of the code, so this was a very learning experience.

The way that sending is implemented in our code.

The communication software has been elaborated since we first started. A very schematic overview of the software is given in the figure at the bottom. Here the different lines represent dependencies on each other. The lines that run between the bricks or between a specific brick and the earth pc represent IR communication. This is done using the Lego Network Protocol (lnp.h).

Software

On the Master brick a listeninginterrupt is installed, this is a so called software interrupt routine, meaning it cannot be controlled by the user and will be called every time that there is IR communication (figure below.

Therefore no CPU intensive code can be included here, as this will result in system failure. This interrupt copys data to a specified location and will set a flag triggering the wait_event in the processing thread. This way cpu load is manageable.

Looking at the picture at the bottom, the master interrupt receives information from the earth pc as well as the Slave brick. To ensure that IR communication is not overflooded every time the brick communicates with earth, for the temperature or to receive coordinates, the Slave brick is told to stop sending by means of controlling a wait_event on the Slave brick. This can be seen in the figure looking at the com_temp and com_earth functions. These functions send out a signal controlling the SENDING variable shown in the Slave brick. This variable is the trigger for the wait_event within the Sending thread.

The Processing Thread on the Master will process all the information and will set some global variables (COORDINATES or LIGHT_ACT). Furthermore it sets a semaphore called ALIVE to the value of 1 every time it executes. Looking at the figure the Watchdog thread is also connected to this semaphore, this thread will set the value to 0 every time it runs, furthermore it runs at a set frequency and it will count the times it runs when ALIVE is 0. When more than three instances occur it will set the NO_COM variable to 1. This is the sign for the Master brick that all communication is lost and all driving is stopped.

Returning to the Slave brick there is a Backup Thread that will monitor how long the Sending Thread has been shut down. After a specified time the SENDING variable is set to 1 again, resulting in triggering the wait_event and firing up the Sending Thread. This is a built in safety to make sure that sending is reinitiated even when the START commando from the Master brick for some reason has not been received.

Figure 1: Software overview

Function usage

Within the rest of the code when include the given communication files the use can call two functions. Com_earth() will result in getting coordinates from the earth pc, returning FINISHED or NOT_FINISHED. Com_temp(value), will send the value as a temperature to the earth, also returning FINISHED or NOT_FINISHED. This way we can check whether communication is successful.

Lnp-dump

Now all loose functions are ready, it is time to put them all together. With the lnp-dump it is possible to receive the bits and bytes send by the two bricks. After installing the software, all data which is received by the tower is displayed. Not only the logical layer of the messages is displayed, also the integrity layer is shown. It does not matter what the destination address of the package is.

Approach lake

When a lake is detected, the rover still has to drive to the lake. To drive to the lake, a function “approach lake” is written. This function is called when coordinates from earth are available.

Software
The coordinates that are received from the earth computer, are used to build an array.This array contains the steering angle and direction, and the distance that has to be driven.

To calculate the steering angle, the position of the lake is compared to the center of the image. Because the distance from the rover to the lake and the distance from the lake and the deviation of the lake to the straight forward direction of the rover are known, the steering angle can be given. For example: when the deviation to the middle is 10, the steering angle for a lake at 20 is twice as large as the steering angle for the lake at 40. See the figure below for a graphical representation.


During driving the new calculated path, the rover will stop to check whether or not there are new coordinates. When there are, the rover will recalculate the path, and continue driving this new path. When there are no new coordinates, for example because there was no communication, the rover continues driving the old trajectory.

When there is an edge detected, the lake approach software gives a “not finished” command to the strategy software, which determines what to do. When the lake is detected, and when this is confirmed by triggering of the middle light sensor, the lake approach gives the command “finished”, which triggers the strategy to measure the lake temperature.

Function usage
The function lake approach is called by the strategy function, and runs by itself, using the edge detection on the slave brick and the communication with the earth. It also uses the path executer to give the steer and drive commands to the rover.

Edge Detection

After some testing of the lightsensor on the mars landscape, we discovered that the light deviation on the landscape was between 1 and 6 light values. The light deviation between the landscape and the edges is approximately 12, the deviation between the landscape and the lakes 10 and between the landscape and the middle of the landscape 5. This last small deviation makes it difficult to detect.

Software
To be protected against not detecting the edges, or detecting several light deviations on the landscape as edge, some software tricks have to be implemented. To be protected, it is chosen to take the mean of the last 50 light values as the light value to be compared to. Using the mean of a array of samples, and updating this array continuously, smooth light changes in the landscape won’t be detected as an edge. The largest advantage of adapting to the surface is that the changes in light when detected an edge will be larger than the changes on the surface. An example is given in the figure below.

Function usage
The edge detection is the main part running on the slave brick. The slave brick is continuously running the edge detection with the communication to send the light value as quick as possible to the master. To send a small as possible code, the light sensors have a value assigned. In this case, the left sensor has value 1, the middle sensor value 2 and the right value 4. Now, all values between 0 (none) and 7 (all) have assigned which sensors are triggered.

The path executer

During one of the brainstorm sessions of our group, the idea of using predefined paths became an interesting functionality. The goal of this path executer is to be able to reconstruct the travelled distance and path quite easy. Software

The path executer is a function that uses predefined paths that are implemented in the code. The five paths that are defined are shown in the figure below. All these paths can be travelled in forward direction, but also in reverse direction. When, for example, an edge is detected, the position in the array is stored. Knowing where the path executer has stopped, it is easy to travel back the part of the array that had been travelled. When the path executer has travelled the given array, it gives when it is finished or not. To detect edges, after executing a step of the array, the value of the edge detection is checked before executing the rest of the array. To prevent the rover from driving off the edge, each of the values in the array should not be too large.

Function usage

Within the rest of the written code, a path can be executed by giving the kind of array that has to be driven and the direction. When an edge is detected, also the last executed part of the array can be given, which executes the path in reverse order to get back to the original position. A graphical overview of the code is given below.