Things i would do differently

I would have been involved in the design process earlier than we did because we left that part till the end and would have thought of better ways for the front wheel which would have been possible if the tasks were properly divided and the meetings organised.

Overall using the mecanno itself was a bad idea because the nuts and bolts engineering set was made of metal and in a project such as this we did encounter some problems when some parts of out circuits were in contact with the metal.

We would try to use another sensing device to detect the change in light intensity which changes the range accordingly.

I learned from watching some other groups that a obstruction around the LDRs with addition of some LEDs was also a relevant approach which could have solved some of our problems.

We could have tried several other approaches to this predicament but if we had managed our time more effectively we could have been successful in achieving a fully functional buggy

Learning Process

Learning process

On the final day, our buggy didn’t show any activity which was a disappointing. It was reacting slow but at least it was reacting on the day before. There were still some flaws with the final program which Hani thought of although as Dr Gareth suggested it was a very relevant approach to develop a program which works with the change in light intensity. We could have used another device which could detect the changing light intensity in the atmosphere and change the range accordingly but this approach would have required further research into the PICAXE programming software. We could have also made the motors even slower as the speed of the car was not specified giving the LDRs sufficient time to react and turn accordingly.

This was a very practical and challenging project which required good knowledge of the PICAXE programming language and it was to me a learning process on the whole as at the start we learned to use case statements and why that program wouldn’t work practically even though in theory we thought we were almost done with the programming bit.

Although I still require a lot of practice on the understanding of the programming language I did get some really valuable experience in understanding the logic behind the written program.

I also learned a lot of things about the design process and how a lot of things that had to be taken into account which we left for the end, such as the weight of the batteries which kept moving and unbalancing the whole buggy causing it to turn in different directions. The skid at the front also proved to be a bad idea as expected while it was being designed. The LDRs which were at the bottom needed to be fixed at certain positions and we used a piece of cardboard which also kept moving when the buggy moved this was also a major design flaw.

Personal Review and My Experience

This project was indeed a nice experience for me. Since childhood I have always been very fascinated by the way robots function. But little did I realize that I would actually come close to making a line following robot myself. This project involved a lot of research work which is no different from other projects, but where this project became interesting is when we had to put all our background information into practice.
Our work was going smooth and all of us were doing good research work for the project. We had decided to put all our individual ideas and programs into practice after the ester vacation. This where I missed out as I got stuck in India for a week due to unforeseen circumstances. When we started testing the buggy one week before the trial date this is when the problems started coming up and all the group mates especially Hani present in the university put in a lot of effort to rectify the problems coming up.
I regret not being able to contribute much as I was missing while the main operations were being done. But whatever part I been of this project was very interesting and nice as I got to learn a lot about the electronics as well as the mechanical aspect of the buggy. Although our buggy did not function properly but at the end of the project I am clear in the head as to why the buggy did not function properly and what could have been done differently

Personal Opinion-Usman

Right from the start of this module, I had a feeling that this module was going to be very challenging and tricky. My feeling got stronger when we were told to make a line following buggy on our own initiatives and as group exercise. I tried to use all the knowledge I gained in this module to make a perfectly working prototype. During this period, I learnt many new things. For example, recognizing our mistakes and correcting them on the go while doing the programming and making the circuit. I had looked at many different ideas for making the chassis as shown in my posts but then after discussion, the group came up with the idea of Meccano. To achieve a perfect design, I had to make many changes. So in a way, this project made me realize that there are different ways to do certain things but to come up with the best one we have to make decisions and test them.

Although we did not achieved the fully desired objectives of the project but I am still very happy and excited about this project because in my childhood, I used to see robots on T.V screens but did not knew that one day I would be making one of these with my team mates. Another positive thing about the project was that I feel much more confident know to implement my knowledge practically and this projected also enhanced my abilities to work as a team member and perform my duties well. Not to forget my group because all of them were very co-operative. Although two of our project members were stuck abroad but still all of us tried to give deliver our best in this project.

As a closing statement, I conclude that “Completion of every small task is a positive step towards success”

Test Day(Faults and Possible Solutions)

Test Day(Faults and Possible Solutions)

On Tuesday morning, we tested the buggy with the final code to make it achieve the project objectives. As seen in my video posted, our buggy recognized the change in colour intensity and did follow the black line but the main problem was that the motors were too slow to react to the changes. By the time one motor went off and the other came on, the buggy had passed over the black line.

This made us worry and Hani tried to change the program and circuit to make it perfect but it was our bad luck. He changed the program and we programmed our buggy for testing. But the buggy just went in a straight line instead of following it. Then we tried to use the previous program but it also didn`t worked.

Possible Faults:

1.LDR Senstivity:

The two sensors had different ranges of operation so the difference (range) between them was fluctuating and was not constant. In our case, we wanted it to increase but it was below 10 so the program did not execute.

A possible reason for varying LDR range is that the light in the different parts of the room was not constant. If the sensors were working fine, our buggy could have followed the lines easily.

2.Connection Problem

There could have been a possible problem in the motor because we noticed that our battery pack had blown up so a possible reason was problem in the board or even in the circuit board itself.

3.Skid

A Problem in the design was the skid we had chosen because although the skid was slippery but it was not able to run smoothly on the track. It got stuck on every joint between the two tracks.

Possible Solutions:

After recognizing all these problems, following are possible solutions to the faults.

1.Introduce a time delay mechanism in the program so that the buggy moves slowly and the have LDRs have plenty of time to react to the changes in colour. This would make the buggy work perfectly and without any problem.

2.Using a circuit board which does not get heated up or using high voltage batteries so that they do not over heat the board and cause any short circuit.

3.The Skid can be changed to a small ball bearing which can roll on all surfaces and is not affected by joints of track or anything else. An example is shown below.

Testing Day

On the testing day our buggy worked properly when we tried to make it follow the black strip but later on something went wrong and it couldnt quiet follow the black strip it had to. According to me the buggy did not follow the black line properly because the range of LDR value we had kept for a condition to become true or false always changed. This happened because the light intensity differs with slight change in the surroundings and with the change in the light intensity the value of LDR also changes. As my group mate(Hani) said we could have had a third sensor which would detect the change in the light intensity of the surrounding and according to that would have changed the ranges of LDR values we had set for conditions to become true or false. Or perhap we could have used some other sensor instead of LDR whose value doesnt change so easily.
Another problem that was visible was the late reaction of the buggy to turn. By the time the buggy could sense that it has to take a turn, it is already off the track. To correct this we can programme the micro-controller in such a way that the moment it has to take a turn, the buggy should pause for a moment and after pausing for a sec or two one of the wheels should rotate in the opposite direction while the other should stay still. This mechanism would keep the buggy on track even if it is responding a little slow at the turns

Circuit Diagram of our buggy

Connection of motor to the micro controller

Using Conditional Statements and Functions

main:

readadc 1,b1
debug b1
readadc 2,b2
debug b2

if b1>200 and b2<200
goto turnL

if b1<200 and b2>200
goto turnR

else
goto front

front: ;this is when the ldrs dont detect any change

low 1
high 2
low 3
high 4
goto main

turnR: ;this is when the rite lrd is on the black line

high 1
low 2
low 3
high 4

turnL: ; when the left ldr is on the lack line

low 1
high 2
low 3
low 4
goto main



The idea of this program was that when the ldr detects a black line it sends a signal to the microcontroller asking it to stop one of the motors , so that the buggy turns and stays on the path.

For example when the left ldr will come over the black line, it will send a signal to the microcontroller asking it to stop the left motor. on stoping the left motor the left wheel will become stationary and the right wheel will make the buggy turn. so in this way the buggy will stay on the path and will follow the line
similarly when the right ldr is over the black line it will send a signal to the controller asking it to stop the left motor so that the buggy turns right. If the ldrs dont face any black strip it would continue to move forward as no signal will be send to the controller and the wheels would continue to rotate as they are

Final Buggy Outlook

This is the final picture of our line following buggy. The chassis is made up of steel to provide a good support to the electronics placed on the top of it.The chassis is made firm with all the joints firmly held with nuts and bolts.
The main board and all the electronics are placed on the top of the chassis. the electronics consist of a pair of simple motors to make the wheel move, batteries,micro controller, motor driver,variable resistor and LDR which are used as sensors.
The motors are not directly connected to the micro controller because microcontroller cant power the motors, instead a motor driver is used which provides the necessary required power.
The electronics are placed on the chassis in such a way that the weight is equally distributed and the stability of the buggy is maintained. The motors are placed beneath the chassis so that due to its weight it pulls the entire body downward and increses the stability.
The two LDRs are placed at the front near the skid. The LDR here are used as sensors therefore they are not covered and are placed at the front. A skid is provided in the front. Since the ultimate aim for our buggy was to follow a line, we thought that the friction that will come into play could be ignored. Moreover we didnt get a free rotating wheel to place it on the front. But never the less, the skid in the front region provides stability to the buggy

Another Attempt at Programming

readadc 1, b1
readadc 2, b2

select case b1
case 0 to 80
low 2
high 1
case 81 to 200
high 2
pause 600
low 1
end select

select case b2
case 0 to 80 ;on detection of light
low 4
pause 600
high 3
case 81 to 200 ;if the light isnt detected
high 4
low 3
end select

debug b1
debug b2

goto main

What did I learn from this project?

Its always far from perfect at first go. You learn new things as you go along. First we discovered that the selectcase statement would only work at certain light intensities. re-wrote the program to tackle that problem, than we find out that the program takes too long to run and react how we want it, so than we tried adding pauses in attempt to almost physically direct it back to line.

It is all a long learning process in which you find the mistakes and try to desperately change them. I would say the most challenging and exciting part of the buggy was testing it. When there was a reaction from the buggy it would make me happy and when its the wrong one you try to read the movement and try pin pointing the mistake in program.

Programming was not easy. There were many different methods to achieve the objective and every method had many programs that can be written differently but based on the same method. I am able to understand the logic of programming much better now, but I still lack the ability to write shorter programs that achieve similar results.

Overall I was happy to be part of this project. Learnt a lot from it and seen how important testing the buggy after every single stage is. I found it more interesting than the crane project because it had more of a physical aspect to it since we were able to see the results of our work whereas with the crane we just hope we are right.

What went wrong on the day?

Our program never successfully followed the line due to the fact it reacts late to turn and by the time it does turn it has already drifted off the track.

But during the test day it did not show any signs of activity. this was because the range of change the sensor would show from when its on the white surface and the black line was not going over 8. and the program would only react if the change was over 10 on one wheel and 15 for the other (because the LDR ranges were different)

reasons for this drop of range is because there was either too much or too little light. as Dr gareth suggested we could have adapted a third sensing mechanism that will detect how much light is in the room and change that range respectively.

Even if the light intensity was exactly how we wanted the buggy would still haven't followed the line in my opinion. But at least it would show more activity.

Circuit Diagram

This is the general circuit diagram with all the connections that we have used for our project.
But in this circuit variable resistors have been used with the LDRs, we were using resistors of fixed value in our final design.

Buggy Video Before Test

This is the video I made just before the test. In this video you can clearly see that the buggy reacted very late to the black line but it did follow the black line. I think this was actually due to the slow reaction of the motors because there is a big time delay in one motor going off and the next one to turn on. This is what happened and I know that if i could have made the black line long enough, we could have seen more motion of the buggy.

After seeing our buggy do this, Hani tried to change the program to remove the time delay of motor switching but at the last moment, we were unsuccessful and our buggy went straight instead in the test.

If we would have left the program as it is in this video, we might have got more marks.

I will be uploading the "Reasons for failure and what we could have done to counter them" in my next posts.

Buggy Completed Pictures

These are the pictures of the buggy I took just before the test.

A NOTE ON DESIGN

As you can see that the whole circuit is very well built and is simple. It does not have bunch of wires spreading all over the place. Also the circuit is resting on the maccano and it has got a skid made of plastic so that it could slip easily. The cardboard used is to make the two sensors stable.

The distance between them is about 30mm so that they are evenly spreadout of the black line.Note that there is nothing on the sensors to cover them because the program used for programming the buggy is based on difference in the readings of the sensors when they approach the white and black surfaces.

Overall the design of the buggy is quite unique, clean and simple but yesterday, the buggy failed to get the desired result we wanted to get. I will discuss more about the test day in my next posts.

Motors and Movements

Just before posting the final pictures and video of our buggy, I think that it will be useful to post a general view of how we considered the movement of motors in our buggy.

This diagram shows that how the direction of buggy changes by varying the spped of the 2 DC motors.

Movement of Motors:

From microcontroller we cannot connect a motor directly because microcontroller cannot give enough current to drive the DC motors so instead we use a motor driver. The motor driver takes the input signals from the microcontroller and generates corresponding output for the motors.

The table below shows different directions of both motors and the corresponding motion of the robot.

Left Motor	Right Motor	Robot Motion
Straight	Straight	Straight
Stop	Straight	Left
Reverse	Straight	Sharp Left
Straight	Stop	Right
Straight	Reverse	Sharp Right
Reverse	Reverse	Reverse

General Circuit Diagram

This is a general circuit diagram of the circuit that i have sketched. It shows all the connections that we have made on our breadboard. I will be posting the pictures of the completed circuit soon.

Rough Circuit Diagram Of Completed Circuit

This a rough sketch of the connection made in the circuit. I split into two diagrams ,Input and Output so that the wirings are clear.

Bill Of Materials Used

ITEMS		PRICE(£)	Buyer
Black Tape		2.99	Usman
Soldering Wire		2.50	Hani
Meccano Truck		7.50	Usman
Meccano Car		3.00	Usman
Gas Soldering Iron		33.00	Hani
Gas Refiller		4.50	Usman
Batteries		2.00	Zaeem

These are all the materials that we have used in our circuit to make it to high standards. All these payments will be shared between us equally. If I have missed any item, please inform me and please note that these prices are all approximates so might me a bit up and down than the original price.