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.