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.

Off-line testing

Now that the communication between the two bricks and with the master brick and the earth is accomplished, is comes in hand to run tests off-line (so not on the landscape). The simulink files from the earth computer were copied to one of our own computers. After some modifications on the files, we can send our own coordinates and receive the temperatures send to the tower.

ZigZag

Today, the ZigZag mode, using the path executer is tested. Now, the rover is able to drive at the Mars Landscape without falling off the edge. (The movie is played at 4x speed)

To detect all the edges, the mean light value of the last 50 measured lightvalues are averaged and compared to the current light value. When the deviation between the average light value and the current lightvalue is too large, an edge is detected.

Data structure

To prevent too large .c files in our software, we wanted to split in into subfiles. To achieve this, we named all the functions to their functionality. For example, the path_executer is named as motion_path_executer.c. To include all the files, the #include "motion_path_executer.c" command is used. Now, a main file can be used to call all the necessary .c files. Doing this, all the code is still orderly. Futher, all the defines are initialized in a "master_initialize.c" file. Here, all the defines of all the functions on the masterbrick are collected, to prevent double usage of defines.

Software Tree

Before buidling all the software files, a software directory tree is build. In the figures below, the structure for the master and slave brick are graphically represented. The white bubbles are the threads, the blue are the function modules and the green are the low level functions and the yellow bubbles the drivers.

Temperature Lake

When a lake is found on the landscape and the rover is standing still before it, the temperature has to be measured. After this measurement the temperature has to be send to the earth.

Software
For measuring the temperature of the lake, the temp sensor and the temp motor have to be activated. After a certain time it is assumed that the probe measures the same temperature as the lake. If no temperature difference is detected, the probe is held in the lake for a longer time. When after five times no temperature difference is measured, the function returns to the strategy that the probe is probably besides the lake. If the measurement went well, the temperature is communicated to the earth.


Function usage
The function Temperature Lake is called by the strategy function. The function runs autonomous. If an error occurs, this is reported tot the strategy.

Bypass Edge using Path Executer

After some work on a path execture we tested it today with some arrays. The concept of the path executer is that it can perform an pre-described motion using an array in counts. For example you have { {-10,500}, {0,300}, {30, -200} }, then the rover will first steer to minus 10 en drive 500 counts, then it will set its steer straight en drive again. Using this, different function can use the same basic moves. While driving forward it checks for edges, if an edge is encountered it will return the position of the array to the level-up function so it can decide how to react. In this way we know exactly what distance was driven. The path executer also has the ability to reverse a whole path or just a part of the path so we can reverse the driven distance. In the video below an action is shown. The rover detects an edge and reverses, then it performs a (first untuned version) S-Corner to bypass it. This also indicates that the rover reacts on the slave brick, which sends the edge to the master, which determines what is going to happen.

Temperature sensor callibrated

Today, the temperature sensor of the Lego Brick is calllibrated with use of a callibrated thermocouple. Now, this data can be used to implement into the final software.

Testing edgedetection and communication

Today we tested two things on the actual marslandscape. The Slave brick was equipped with 3 light sensors and communication broadcast ability. The Master brick (shown in front in the attached movie) was equipped with recieving software. This brick will show the status of the Slave brick on its lcd screen. 0 for no edge and an integer if an edge is detected (light1 + light2*2 + light 3*4). Furthermore the Master brick will produce an audible beep when more then 3 packages are lost during communicating. This is simulated by turning off the Slave brick and then turning it back on.

Chess LineTracking Competition

This afternoon, the Chess LineTracking Competition was held. Unfortunately, our rover did not wanted to drive as it should by, which did not give us a decent time and distance. After the regular time, we gave it another try, which made the fastes and most accurate drive afterall. The length of the tape was 1034mm and the winning distance was 1028mm, while we measured a distance of 1030mm. Bad luck.

Tornado

Todat our group was hit by a tornado. Wesley decided to step down because he was to busy with his master project. So his tasks have to be taken over. Second, we decided to change our brick setup to remove complexity. This resulted in a whole new idea what could be an interesting result - more will come. It differs from the standard idea. Furthermore we completed the whole sheme how all in- and outputs should work, some basic functions were already written like steer, drive, the communication and the temperature module. Now the more complex part will be programmed. Next is the linetrack on Monday the 11th of May to show our linetrack capabilities.

Working testing version of communication

We wanted a reliable and fast communication line between the two RCX bricks. When looking at our needs we wanted a program that could send a given integer with a predefined interval. Furthermore code on the recieving side must be able to continously monitor activity and act upon moments of no communication. Therefore an own communication program has been written that on the sending side will broadcast the specified integer and on the recieving side will process that number and will monitor how much time there is between two packages. If this time exceeds the prespecified time then action is taken. A test version of this program was able to continously send a altering integer from one brick to another with a frequency of about 15 hertz. The recieving brick was able to remotely shutdown the sendingthread on the other brick after a specified number of packages.

SubVersionServer

Assuming that a lot of code has to be written, and a lot of versions of code will be available, it is chosen to use a sub version server system. After searching the internet, dopbox was found as a good option (https://www.getdropbox.com/home). Using dropbox, old versions can be restored and all the group members are able to search all the code.

Line Tracking

After rebuilding the rover and recallibrating the steering, the rover is able to track down any kind of tape.

Rebuild

Wednesday the 8th of April we decided to rebuild the Rover. As can be seen on the picture below, we completely destroyed the rover before rebuilding.

Line tracking test

Yesterday we built a first version of the edge detection. The edge detection is able to detect a color change and store the states of the three lightsensors in one integer. Today we made a set up for the linetracking and implemented this. A first test was done and for a first test it was succesfull. The rover was able to track the line and count the length. However the were some problems with the hardware so the steering was not perfect. So next we are going to fix the steering in the hardware and also we are going to improve the algorithm for steering in the sofware. Movies of the line tracking will be post soon.

Communication

Next to the driving and steering of the rover, the communication is also important. After installing the basic programs for communication on the bricks, the robustness of the infra red was tested. It seemed hard to interrupt the communication between the bricks.

Measurements with the encoder sensor

Today we did the first measurements on driving with the encoder. We wanted to verify the accuracy and reproducibility of the encoder sensor. Therefore we wrote a program stopping after a set number of counts and by measuring the distance we can get an idea of the reliability of the sensor.

Finite State Machine

Last Thursday we had our first meeting with our tutor, Arjen den Hamer. First we studied the mars landscape. Then, during the meeting we built a Finite State Machine. Afterwards we extended the Finite State Machine so we have a clear overview of the software to be programmed. We defined the functions and its in- and outputs. Now, the basic functions can be programmed so we can include them in higher level programms.

Cliff Detection

The first tests are done with the marsrover using the sensors and actuators. Our first programm is 'cliff detection'. Using one light sensor we check if there is a cliff, if so reverse. The change of state is printed on the brick namely 'cliff' and 'drive'.

First program is running

The first communication between the mindstorm and a XP laptop is completed!

There is still a problem with communicating between a Vista laptop and the Mindstrom...

Start Embedded Motion Control

This blog is for the members of group 4 for the course Embedded Motion Control 4K450, with the members:

Ivo Hamersma

Geert-Jan Heldens

Wesley Ooms

Gerbert van de Ven

Jeroen Willems

This blog is to show the progression of group 4. When there is some new information available, it will be posted here.