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