Finalizing the code

The three tactics have been thoroughly tested and found to be working individually (see other video's). However untill the very last moment, problems had to be overcome with the camera. Sending coordinates proved not to be robust and with limited available test time, it didn't help that the earth computer stalled every two or three tries. If the camera is fully operational tomorrow, we hope to be able to show the tactics working together in a single program, and to find all the lakes within a reasonable timespan!

Tactics part 3

Goal
- Measure lake temperature

Tactics
- When mars rover is not standing above a lake the mars rover drives in a straight line until lake is found with one of the light sensors
- When lake is found the measuring device is let down. If the device hits mars instead of the lake the touch sensor (seen the picture below) is not pressed and the measurement is neglected. The rover will than turn a certain amound of degrees and try again until touch sensor is pressed and measurement is valid.
- Temperature is sent to earth computer
- Turn to tactics part 1

Execution:
Tactics part 3 has been tested as can be seen in the movie below.

Tactics part 2

Goal:

- Drive to lake

Tactics
- Transform camera coordinates to mars coordinates 
- Plan path to lake using map (straight if no edge detected)
- Drive to lake, approaching up to 30 cm. 
- Use camera to position marsrover straight in front of lake, turn to tactics part 3 (also when no coordinates received)

Execution:
Transforming the camera coordinates to lake coordinates was enough to crash the brick time after time. The transformation of the coordinates and the path planning exist in code form but have never been tested due to the crashing. We decided to comment this part and first make sure tactics part 1 and 3 would work properly.
Tactics part 2 now turns the rover in such a way that it is standing straight in front of the lake and than turns to tactics part 3. This has been tested. All intelligence is turned off for now, we hope to be able to use it in the end, but priority is now to get it to work as simple as possible.

Tactics part 1

Goal:
- Find coordinates

Tactics
- The mars-rover turns 360 degree searching for lake coordinates. (Turn certain amount of degree, waits for coordinates, if no coordinates received turn again certain amount of degree with maximum total of 360 degree).
- If no coordinates are found after turning 360 degree the marsrover drives a random distance and again starts turning and searhing for coordinates,
- If during turning coordinates are received the software turns to tactics part 2.
- If during random driving a lake is found the software turns to tactics part 3.


Execution:
Tactics part one is created and tested. It works fine.

Moving on Lightsensors

Due to our extended calibration file we were able to move quite well on the lightsensors. However, during testing on mars, especially at lower light intensities, moving on the lightsensors seemed to be not robust enough. Updating the tresholds during driving was necassary.

New method:
During calibration ten measurements are performed (per sensor) and stored in an array. A new measurement is now compared to the average of this array. If the new measurement doesn't differ much the robot concludes that it is probable on mars and the new measurement is stored in the array. In this way the array is completely renewed every ten measurements, allowing the surface to vary.

Presentation and line tracker contest

Last friday we did succesfully our presentation about the mission to mars contest. The slides can be found here.

The line tracker contest didn't went that well. In the morning, during testing, the tracker worked fine. But the focus will now be totally on the mars mission!

Earth communication

Since multiple groups are still struggling to achieve communication with the earth computer we decided to release our code which allows communication with the earth station. The code consist of the comm.c library with some modifications to make everything work smoothly and the camera.c which consists of a function which sends a temperature to earth and reads the camera. In order for the code to work, cam_x and cam_y should be initialized as integers thread id's need to be created and communication should be initialized the same way as usual. The files are listed below:

http://dl.dropbox.com/u/15883361/camera.c
http://dl.dropbox.com/u/15883361/com.c

Camera to coordinates

Yesterday we started working on translating the position of a lake in pixel on the camera to the x-y position of the lake with respect to the rover. Instead of the usual approach of using the camera position and goniometrics to derive the coordinates, we decided to create a lookup table to transform the camera output to coordinates. Below is a picture of what the camera sees with a grid superimposed on top. The nodes of the grid have certain pixel coordinates, and corresponding "real world coordinates". Using this data we created a lookup table and fitted parabolic functions in matlab to describe the camera's field of view for each "real world coordinate". By transforming the lookup tables into parabolic functions we avoid using vast amounts of memory for storage.

Below are the surface plots with on x and y the camera output in pixels and in z the corresponding distance in x & y in mm.

Presentation / pictures Mars Rover.

Today we made the first version of the presentation for friday about our Mars Rover.

We also want to show how our linetracker and mars rover looks like up till now, see understanding pictures respectivily left and right. The camera standard has already been made but is not attached in this picture. Furthermore one can see that there is a fancy spoiler on our linetracker and mars rover ;-).

Motor controllers finished

The motor controllers have been working for about two weeks now, however the blogging had a little delay. There used to be a problem with reversing the direction and the problem was found to be in the abs() function. This function returned an int, while floats were required for the controller calculation. The robot drives in a straight line with input values a speed and a reference distance in mm and it is able to turn with input variables angle in degrees, turn speed and direction.

Smart driving using the map

Keeping track of edges on mars makes it possible to do smart path planning. Once the robot has received lake coordinates from the camera, it will check if a straight line towards the lake is possible. If there are known obstacles on the way, a new path is planned, avoiding the obstacle. Of course the map is completely empty at the start, so it might occur that the robot finds an edge on its way. This is then added on the map and a new path is planned, avoiding this edge too.

Finishing the linetracker

Yesterday the linetracker was finished. It will now beep before and directly after the measurement. Furthermore, our beautiful calibration file is removed, because we are not allowed to calibrate 10 seconds before the competition.

Problem sending lake coordinates to brick solved

Last week, just before the holidays, we were succesfull in the final attempt! We had to change the com.c file to be succesfull. A semaphore was created so that two functions cannot do their job at the same time: receiving the coordinates values and writing them in to the memory. Today we checked if our success wasn't a one time lucky shot and luckily it wasn't! Further programming was done to save these coordinates so that our 'tactics department' can test with these coordinates.

Problem sending lake coordinates to brick

Since two weeks, we have spent quite a lot of hours on the program that sends the lake coordinates to the brick. But we still aren't lucky in succeeding. Today the com.c-file has been adjusted in such way that we know now that the problem lies (probably) in the way the data is copied to the memory. More research needs to be done to receive the coordinates on the brick.

Communication Delay 2

After a week of hard work we solved the problem with our communication by changing the way the threads function. Previously we were starting and killing threads in a while loop thus creating a large amount of overhead for the operating system. The new code uses only one thread for communication which loops as long as it's active thus reducing the amount of threads running and significantly increasing the performance of the rover.

Communication delay

Yesterday we experienced that our communication is indeed working, but it is not yet suitable for our mars rover.
There is a huge delay between the moment one brick finds an edge and the moment the other brick reacts (stops). The delay can be seen in this video. The moment someone puts his hand just below the light sensor the right brick detects that all sensors are above land and sends a signal "clear to drive" to the left brick. This brick will then start driving.

We have a few options to test left. Hopefully we'll find a way to reduce the time delay soon.

Motor controllers

Early tests with the line tracker have shown that the same input value to a motor can yield a totally different speed for a different motor. In order to drive in a straight line, the motor speeds need to be controlled. Of course the preferred way to do this is to use the encoders.

The original idea was to make a control loop as can be seen in the included figure. The idea was to only regulate one wheel speed and make it go slower or faster than the other wheel according to the encoder difference. This was found to be rather difficult since the speed doesn't increase linearly with the motor input value. So the decision has been made to only slow down a wheel if it leads in number of encoder counts over another wheel with a minimum speed of 0 (so no speeds are allowed opposed to the direction of propagation).

Today, work has continued on the motor controllers. A function drive_controlled(ref_dist, speed) has been made with input variables a reference distance (so far in increments, however this will be millimeters) and a speed value. The function has been programmed in such a way that a negative reference distance will automatically switch the motor directions, so speed can be implemented in an absolute manner.

The controller consists of a proportional gain only which is multiplied with an error signal. The error is defined as the difference of the absolute value of both encoder signals.

Activity diagram: mars mission version 1

We made an activity diagram for the mars mission so that it would give us more insight in the steps that have to be made in the process. Several of these 'blocks' in the scheme can be subdivided into other blocks. But the meaning of this is scheme is just to give a global overview.

Implementation Communication completed

Today the communication has been fully integrated in the main brick files.

The three light sensors are connected to brick two. Brick two reads out the light values and interprets them. The interpreted value’s now have to be sent to brick one. The motors of the wheels and the encoders connected to the wheels are connected to brick one. Brick one receives the interpreted value’s send by brick two and is able to take measures based on these value’s (brake, drive, turn, ect.).

Experienced Difficulties.

We did experience some trouble when integration the communication software in the main files (main file of brick one and brick two). We had some trouble with the while loop in the main file containing the read and receive threads used for the communication. The trouble was that after passing trough a few loops, brick one would no longer receive the send values. It turned out we had to terminate the treads at the end of the while loop, otherwise every loop new threads would open.

Activity and component diagrams of the Line tracker

We forgot to post these diagrams before, but they give a clear understanding into the requirements and the steps that need to be implemented in order for the line tracker to function properly.

Mapping Mars

We've written a program which by keeping track of the light and rotation sensor readings can make a map of the surface of Mars. The map consists of 6 columns of 96 integers. Since one integer has a size of 16 bits, we can store by using bit shifting 16 booleans in one integer, thus creating a bitmap of 96 by 96 bits. One bit corresponds to a surface on Mars of 5 by 5 cm. A 1 on the map corresponds to ground while a 0 corresponds to an edge.

Light Sensor Tests

Today we tested the light sensors on the surface of Mars. We discovered that, due to the small variation in brightness between the surface and the abyss, the light sensor readings are not sufficiently sensitive. To bypass this problem we changed the way we access the sensors to increase the resolution by approximately a factor 10. The sensors now work sufficiently well to tell the difference between Mars and its edges.

What to do with the hardware of the Mars rover

Today we had a general meeting. The linetracker is almost finished so our target is now the mars mission. The hardware of the linetracker will be the basis for our Mars rover. Thus it will be a rover with two big wheels, driven by a motor and checked by a rotation sensor. There are lots of possibilities to place the sensors. We came up with two of them. The are drawn in understanding figure.

Explanation of the letters: RS = Rotation Sensor, LS = Light Sensor, M = Motor and RCX = LEGO RCX. Both possibilities have two wheels and the motors and rotation sensors are both placed on RCX 1. The main difference is the way the light sensors are located and to which RCX they are connected. 

In the left rover, there is a light sensor going from the left to the right in front of the rover to check for edges. The motor and light sensor are also placed on RCX 1. The other two light sensors and temperature sensor are placed on RCX 2. The advantage of this option is that the rover can drive and check for edges with only one RCX. So there is no need for immediate connection with the other RCX. When an edge is detected, the rover will drive very slowly until the other two light sensors determine where the edge is and pass this information back to RCX 1. If there is a lake in front of them, the temperature will be measured and driven by the motor that also drives the light sensor placed on RCX 1. 

The light sensors on the right rover in the figure are placed in line in front of the rover. These light sensors are all connected to RCX 2. The temperature sensor, motor and rotation sensor to let the temperature sensor go in the lake are placed on RCX 1 together with the motors and rotation sensors for the wheels. The advantage for this option is that it is easier to determine what kind of edge the rover is detecting. Only the problem is that RCX 1 and RCX 2 continuously need to communicate to each other. The question is how good this connection will work.

After a discussion we have chosen for the second option. The problem with the communication will be solved with the idea that if RCX 1 doesn’t get data from RCX 2, the rover will not move any further. Only when the connection is reestablished, the rover will drive again. With this solution the risk of falling off the platform is much smaller in comparison to the first option in which edge detection is quite difficult. On the RCX 2 only three sensors are placed, which leaves probably much room to store mapping-data. 

With this conclusion we divided the work in a few groups. The work that needs to be done for now:

• Research on how the camera works, how it gets its data, etc.
• Improving the edge detection (how to deal with varying surface, etc.)
• What to do at the start (safe driving)
• Architecture
• Mapping
• Hardware

Temperature measurement

Today the temperature sensor is tested. For some reason the danish decided to use the Fahrenheit scaling. We don't read Fahrenheit so conversion to Celsius is applied.
The sensor is tested in hot and cold water, it seems to react real slowly. To make sure that the temperature is measured correctly the program will do a measurement, wait for 3 seconds and then perform the next measurement. If these measurements result the same value we assume the measurement to be correct and finished. (if not it will wait another 3 seconds and measure again etc.)

Communication

Today the two programs for Communication between the bricks has been finished. One of the bricks gets ID 2 and sends information while the other brick has ID 1 and receives information.

Light Sensor Calibration

Today the two calibration programs for the light sensor have been finished. The working of both programs is written down below.

Program one:
//Calibrate light sensor for line tracking
//
// During this calibration the light sensor is first placed above the black line.
// When pushing the 'view' button the light intensity is stored in Brightness_line.
// Next the sensor is placed above the table, when pushing the 'view' button
// light intensity is stored in Brightness_table.
// The stored value's are also "printed" on the LCD screen once the button has
// been pushed.

Program two:
// Calibrate light sensor for mars exploration
//
// During this calibration the light sensor is first placed above mars.
// When pushing the 'view' button the light intensity is stored in Brightness_mars.
// Next the sensor is placed above a lake, when pushing the 'view' button the
// light intensity is stored in Brightness_lake. Last the light sensor is placed above
// the edge of mars (a meter above the floor), when pushing the 'view' button the
// light intensity is stored in Brightness_edge.
// The stored value's are also "printed" on the LCD screen once the button has
// been pushed.

steering

Today our linetracker learned to make turns with all possible radii. This makes it possible to gradually steer, instead of the jerky movements of last week. In this video the robot starts to drive in a straight line and it gradually steers sharper until it turns around its center.

Linetracking version 1 (movie)

Because we don’t have a lot of time, we had a meeting yesterday in which we checked our Mars rover and gave everyone several tasks.

Today we have built a robot with three wheels for the Line-tracking competition. The first movie shows the robot in which a program has been designed just to show how the robot reacts on the input.

In the second movie a second version of our robot is already able to track a black line. This is a very raw version, so a lot of things have to be adjusted to create a perfect line tracking robot.

Let's start!!

Finally the course Embedded Motion Control (4K450) has started!

The members of our group are:

Bernadette Tijdink

Arne de Roest

Geert-jan Verstralen

Erik Geerts

Freek Fennis

This course is all about simulating the 'Mission to Mars' and the question if there is water on Mars. Our goal is to find the water! This will be simulated with a Mars rover made with LEGO Mindstorms. The Mars rover has various components available to reach itsa goal:

-      Two programmable interfaces (LEGO RCX 2.0)

-      A camera

-      Three light sensors

-      Two motors

-      Two encoders

-      A temperature sensor 

In the DCT-lab at TU/e a Mars landscape has been reproduced in which 3 lakes are situated. The mission starts when the Mars rovers lands somewhere on this 'planet'. The Mars rover has to find the lakes and then measure the temperature to check it for water! Our main goal can be noted as:

Program the Mars-rover in order to find out if there exists water on Mars. If water is found perform measurements to find out its state.

This blog will show our progression on this project for the upcoming weeks!