Time-management and team-management.

After meeting with Jos we decided to be more organized.

We looked at our agenda and suddenly found out that the Final contest day is within two weeks whereas we are still not sufficiently ready for it. Also we found out that subscription list for using camera is quite crowded. Taking into account a lot of coming holidays time will be crucial. All these facts encouraged us to enforce preparation and start using time and human resources more effectively.

Firstly, we defined main tasks and then split them into subtasks. Then we decided to create subteams which will be responsible for particular task. Based on this we found suitable time slots and distributed activities on two-weeks term. As a result we created a table "2BeDone" as shown below. Next group meeting is tomorrow.

Meeting with Jos, week 7

We met Jos and showed to him results on our line-tracking assignment. He was satisfied by current progress. However, he strongly encouraged us to start implementing LakeFinding assignment simultaneously. Also he recommended us to post conclusions on coding instead of posting code as is.
Next meeting is as usual on Monday.

Line tracking: current results and problems

After implementation of both software and hardware parts which were mentioned before, we made initial tests. These tests revealed some problems to be improved such as:

-Switching movements between rotational and forward movements while specific light sensor positions
-Too sharp rover turnings which yield inaccurate measurements and extreme slalom trajectory

However, we gained good results. This assignment allow us test machine before final contest. For example we will reuse our code and knowledge in areas such as:

-Using communication between bricks and Earth station
-Evaluating distance and direction to the lakes
-Using sensors in order to detect landscape edges and plateau
-Control of turn motions in order to choose best trajectory to the lake

Results are shown below as a video. Still they are not ideal but we are on the right track

Line tracking: hardware part

As mentioned in the previous post, we created a programme which performs "slalom-style" movement. Taking into account this information we decided to change hardware part slightly.

First of all we decided to increase sensitivity of light sensors. Robin updated it on software level such that difference between tape and table will be detected more significantly.

Then we decided to increase precision of encoder. Initially, it was connected to front wheel axle directly. It has two disadvantages. First one is that length measurement will be disturbed by curvy trajectory caused by rotations of front steering wheel. Second one is that one full rotation of front wheel will be equal to 16 ticks which is not sufficient for small distance measurement precision. After analysing them we decided to improve mechanical design. We have made following changes.

1) Moved encoder from front wheel to the on of rear wheels
2) Connected encoder to the axle indirectly by using clutch of two ratchets. Ratchet with bigger radius was connected to axle of wheel and transfers rotations to the ratchet with smaller radius. This second ratchet is connected to encoder. As a result, one full rotation of wheel will be equal to several rotations of encoder. Thus, precision of length measurement will be increased
3) Differential connection was added to rear axle.

These changes improved chassis of rover and will yield easier programming together with better results for both assignments.

Line tracking: software part

After successful fixing encoder problem we had two sessions: on Saturday May, 28 and on Monday May, 30. As a result we made a good progress in line-tracking assignment. Hereby I will give short explanation of software part.

We decided to use Master-Slave architecture. It means that two bricks will use different code. Master brick will make main computational work. Slave brick will receive information from sensors and transfer it to the Master one.

It is useful because for Lake finding assignment we will use communication between bricks as well as with Earth computer. Therefore we decided to use com.c library and studied threading and semaphores in BrickOS environment.

Slave brick has a very simple programme. It reads values from three light sensors and rotation encoder. Then it activates thread for reading information from IR port, initializes it and sends values to Master brick which has certain ID

Master brick consists of four motion control functions such as move(), stopDriving(), stopSteering() and steer(int angle). Next service function is init() which initializes all sensors. The function isObstacle(int sensor, int trigger) determines whether rover is on the line or outside it. Finally, main(int argc, char **argv) function realizes main logic of assignment.

Main idea is as follows. Initially light sensors determine contrast values of tape and table. These values are stored and continuously compared with new values obtained from sensors. If there will be detected that sensors are outside tape then immediately direction of movement is calculated and motors steer to the necessary direction according to necessary angle. In order to keep on track forward movement is stopped then rotation is performed. As soon as necessary angle is achieved forward movement is continued in order to return to track. When it happens steering angle adjusted to zero in order to perform straight movement. Otherwise, rotation and steering continued.

Meanwhile, encoder sends information about rotations and this information is transformed to the distance covered by rover. This distance is supposed to be the line length and indicated on LCD of the brick.

As a result, we get "slalom-style" movement which allows rover to keep on the line no matter how curvy it is.

Problem with hardware: encoder malfunction

Yesterday we made initial experiments for line tracking competition. We have done:

1) Activating and receiving information from sensors such as motor encoders and light sensors
2) Implementing initial programme which allows to adjust movements according to information oh hardware

Here we had a problem - one of the encoders doesn't work. It doesn't send information to RCX. We have made a double check - shuffled two encoders and the problem remained. It means that problem is in hardware but not in software. It was a rotation encoder.

Jeroen said that it is not a problem and it is easy to fix. We just need to return defect one and he will substitute it. Hopefully, tomorrow we will do it.

A Three Wheeled Design, Why?

By now, our hardware design is finished. Since the line tracking assignment and the final contest are separated no more than a week we decided to create a rover that can do both tasks without needing adjustments in the design. Furthermore we would like to be original and think for ourselves so we're not using any of the standard designs.

The most important requirements we determined during our first meetings were;

-It should be able to explore the mars landscape with the camera without going back and forth, the rover should be able to turn around its vertical axis.

-Because we will have to use encoder values in order to measure the length of the tape, the wheels are not allowed to slip.

-Hysteresis on the steering mechanism should be minimized, so we can be very sure about the direction we're going with respect to our previous position.

-The risk of getting stuck in a lake should be reduced much as possible.

At first these constrains resulted in a caterpillar like design, but since the wheels that drive the caterpillar might slip within the track, this idea was dropped. Then a more ingenious design with two wheels on the left and two on the right that allow the rover to steer in a caterpillar like way was proposed. But since these tires could also slip, and because one of the wheels could get stuck in a lake, this design was also dropped.

Our final design uses three wheels. Steering and driving is all done on one wheel which reduces hysteresis on the steering mechanism. Because we're using three wheels, the rover is not 'statically over-determined', which reduces the risk of slipping wheels (for the line tracking). Using less wheels also reduces the risk of wheels getting stuck in a lake but it goes at the cost of less stability. That's way we had to put the heaviest parts (the Bricks) low as possible. Below the finalized design is shown with some more explanation.

A – Light Sensors are in line tracking position, the onces on the side can easily be moved more to the side for the Mars mission.

B – Direct connection between wheel itself and steering gear in order to reduce hysteresis. Steering wheel can be turned 90 degrees to allow the rover to turn around its vertical axis.

C – Eyes of the rover are like small crosses, it makes the robot look drunk but this is just to mislead people.

D – We were too late with collecting extension cords, only the very long onces were still available...

E – The motor that moves the temperature sensor up and down is placed in the back to improve weight distribution.

F – Handle to lift the rover without Lego parts falling of.

G – Gear ratio has been slightly changed, compared to standard designs, to make it go faster. Of course it goes at the cost of torque. 

H – To increase stiffness of the steering axis a sliding surface is created with Lego bricks that are placed upside down is created. Scotch tape is used to reduce friction.

Lake finding algorithm:

This is a state diagram of the operation of the robot in order to find a lake. The algorithm is based on the mechanical design of the robot that can rotate the front wheel 90 degrees. It starts by checking if there is a lake in the camera view or not. If not it starts steering the front wheel 90 degrees to the right until it finds a lake or the light sensor detects a hole. On hole detection it steers to the other side searching for a lake. If it finds a hole again then it is between 2 holes and the moves backwards a bit and starts searching again. upon finding a lake the robots move forwards while adjusting the steering degree of the wheel as a factor of the lake orientation relative to the display. when the lake disappears from the screen as a result of dead zone, the robot moves further until the center light sensor finds the lake and it measures the temperature and sends it. In case a hole is detected while moving towards the lake, the robot tries to move around the hole keeping into mind the orientation of the targeted lake. This is a recursive procedure or steering to the other direction then moving forward then steering back until there is no obstacle and the lake is reached safely.

Software planning and chassis improving

Today all five of us worked on project. We started from discussions on chassis design. There were two options. We chose the best one.

Then we split up into two teams. Robin and Serhat made mechanical design. Me, Sergiy and George defined general block scheme of software algorithm as well as modules of software. We found out that there should be three modules - sensors&actuators, image processing&communication, motion control. We draw state diagram and defined information flow chart.

Next meeting is on Monday.

Meeting with Jos

Today we had our first meeting with tutor - Jos.

General conclusion after meeting is as follows. We can use everything we want and there is not any ready solutions. Only approach is to experiment and check.

Also Robin changed the chassis  - now it is smaller.

Next session is tomorrow - after lunch.

Questions to tutor, mechanical changes

Today we met each other in order to discuss questions to tutor. Tomorrow we will have meeting with him and we need to clarify some issues.

For example, we need to know more information about image processing, software architecture, steering mechanics, lake exploration algorithm, line tracking conditions etc.

Also, we found out that there are only 4 weeks left to the final presentation. So we need to work twice a week not once.

As for progress, on weekends Robin made some open loop movements using simple C scripts.

Also he proposed various chassis configurations. This configurations will make rover more robust.

Getting Familiar

This week Robin joined the group and started making up for lost time. He got to know most of the other members and was quickly briefed on progress so far. Working towards our first tutor meeting, the group spend time on getting familiar with the Lego Mindstorms setup and on refreshing knowledge in C. For the latter purpose we've used a pdf of the book recommended by Van de Molengraft; 'The C Programming Language' by Kernighan and Ritchie. Also we've started reading in 'Real-time Concepts for Embedded Systems' by Qing Li and Caroline Yao. 

We've inspected the Mars Rover as provided to us. Two concerns we have are (1) backlash in the steering mechanism and (2) differential behavior once one of the driving wheels gets stuck in a lake. Once stuck in a lake, we expect the Rover to keep circling around it with one wheel stuck because the wheel that's in the lake will be able to freely rotate (allowing the other driving wheel to execute force on the mars surface). Despite these concerns we'll try to focus on developing software first and leave hardware unchanged for a while. Current state of our software is that of being able to execute the various demo examples on the RCX. 

A shared Dropbox folder is created in order to efficiently share project code amongst group members.

Meeting with Robin

Finally, all 5 group members are arrived. Today we welcomed Robin. We gave him short intro on what we already have done.

As negotiated, Serhat, Sergiy and me will not work on coming Monday because we will be busy with another project - Pizza robot. Robin decided to work independently on Monday.

We saw how other groups created new chassis for their rovers. They used caterpillars instead of wheels. That's a nice idea - may be should think about that also.

Initial group meeting results

On Monday we had our first group meeting. We created scratch of a plan for coming 5 weeks. In this plan we outlined basic steps and formulated some problems to solve.

We decided to work once a week on Mondays and spend entire day from 9:00 to 18:00. Also we will use parallel approach when different subgroups will work on different parts. We will make integration after each step as were taught on the lecture.

First problems started with Ubuntu. Each of us has different laptops. Therefore single approach didn't work. Some of us decided to use USB stick, some - CD loader, some - use virtual machine. Me and Sergiy successfully installed USB-stick and made simple examples shown on Wiki and made our rover move straight. Serhat and George still on the way of correct installation.

This week Robin will join us. Next week three of us will be busy on Monday on presentation on Pizza-robot. We need to find solution of this time-overlapping problem.

Group created, tutor assigned

Finally we completed our group. Now we have five persons.

Also, the tutor was assigned. Meeting request was sent to him.

On coming Monday we plan to have initial group meeting. On this meeting everyone except Robin will attend. Robin will join us later.