Final Thoughts - Jason

At the beginning of the project the group got together and from the first meeting I realised the group was going to gel quite well. Every one was very enigmatic and had a decent level of determination towards the project.

When it came to the project I was designated as the chief programmer and at the beginning I had a few options in which to build on to make the buggy work as best it could. The root that I chose in the beginning a simple set of if else instructions which would have done the job as stated however it was messy and the processing time would have down right ridiculous.

From there though the I decided to take the idea of the if else statements and placed them with in a case select routine which may have looked like a rather large set of code but only sections of it were being used at a time, so the processing time was much more rapid.

From there the commands to switch between to case select routines based on the state issued through a switch was implemented. In the simulations the program was perfect and the outputs were executed exactly when the inputs deemed necessary.

However, the only issue that but a wrench in the workings for me was not making the code work in a virtual environment but in a real environment, being the classroom. This was a nightmare since the machine response time was nothing like the electronic response time. The circuitry was fine and the setup was fine but the coding would not complete the tasks no matter how perfect it was on the computer. So therefore calibrations were needed on the buggy so that it would respond in the manner we desired. It took us awhile and I believe that the buggy performed to a decent standard in following the line (well, most of it) and completing part of the instruction stage.

In particular I should mentioned Richard Bay (Bez) being as his job in the project coincided with my job every step of the way. We both worked at a decent level of quality and the circuitry was completed and modified without errors on his part at all.

In conclusion, my group members all performed equally brilliant all through the duration of the project, and all of them were punctual and diligent even through the truly agonizing periods where we thought it was doomed to fail. I was truly thankful for getting put in this group and would gladly work with them again.

Final Thoughts - Adam

My job in this project was to oversee the construction of the shell and the chassis for our buggy and to addapt the design to accomodate any changes in the circuitry and program. I believe I was successful in this task as the chassis was stable and light enough for the buggy to opperate without interference and the shell was constructed and decorated to a high quality, giving the buggy more character than just motors and wires.

During the construction of the product, Rachel and I encountered minor setbacks that needed to be resolved. First, after constructing the the chassis, we discovered that we had not allowed extra space for the wires. Because of this, the motors and the breadboard did not sit in the chassis as expected, meaning that the motors were not straight and the wires kept falling out of the breadboard. Secondarly, we discovered that althought the card chosen for the chassis appeared strong enough, the weight of the motors and breadboard made the middle of the chassis sag down, tilting the wheels in the process so that they did not run true.
To solve this problem, we redesigned the chassis to give room for the wires and extensively reinforced with dowel. This allowed the wheels to run flat, rather than on edge, and made the buggy run straight. However, as chassis 2.0 was larger, changes had to be made to the size of the shell. The shell also had to be reinforced at the joints with dowel to gaurd against warping or bending of the size / shape.

Overall, i was pleased with the finished buggy as it was not just a characterless heap of mecharno which was the chassis build choice of many groups. Althought the programming did not operate as intended, i think that we have done well, as our buggy followed the line and recognised the stop and reverse symbol.

As a group, we worked well together. I am pleased to have worked with such a hard working, focused group of people. I would work with them again in the future.

Final thoughts: Rachel

Throughout this project the team has come together and we have all worked very well together. I am very happy with the final product and even though it isn't perfect i believe it did very well on the course and managed to find its way round a fair bit of the course. It also performed the reverse command perfectly.
My job in this task was group manager and the construction of the base but I also helped a little with the code and the wiring with everyone else. As group manager I wanted to keep everyone on track and make sure everyone was pulling their own weight I believe I was mostly successful in this task and everyone did their tasks in time for each meeting we had minus one.
As for the construction of the shell I talked with adam about material and we decided on cardboard as it is easy to construct, easy to change when problems are encountered and it is also very light weight. However to strengthen it we used wooden dowels as cardboard is quite flexable and this problem needed to be overcome. In previous posts I created a basic CAD model so i could get the dimensions correct and I then made a mock up so that i could test how strong it was and the dimensions.
In the end with a few little changes the design was very succsessful as it was strong, fitted all the components in perfectly and did the job it was supposed to do. Our buggy also stood out from the crowd of mechano which most of the other groups had used.
As for the wiring I helped quite a bit even though the final orientation of the wireing was changed. I also purchuced a bright white LED so that we weren't relying on natural light which is unpredictible.

I am very happy with our buggy, I'm glad I had such a good group for this project and I'm also glad I had the oppertunity to do it.

Final Product

Below is a picture of the finished reinforced chassis with the circuitry inside.

The new design of the base for the buggy is there to mainly increase strength and incorporate the front trolley wheel better into the design. The initial shape has remained the same with a few minor adjustments. The box for the bread board has been widened and the length of motor boxes has been increased as well to incorporate the wires.

Two dowels have been inserted into the corners of the motor boxes and run all the way along the width of the base and two more have been added along the length of the base. These greatly increase the strength of the buggy so that the wheels like on a straight axis.

The hole for the LDRs and LED has been moved to the ‘front’ of the buggy and a skirt has been attached around the elements to stop any unwanted natural light from affecting the readings. This should make the code run faster and the values recorded clearer.

Instead of having a trapeze shaped piece of card at the back of the buggy a small box has been built so that the trolley wheel is kept vertical by two layers of card instead of one.

All of these changes have made the buggy a lot stronger and all of the outcomes have been positive.



Above are picture of the finished painted shell on top of the chassis. Although the shell weighs down the product and slows down the movement speed, it makes the product asthetically pleasing and covers up the circuitry, making the product look neater.

Coding Final

The final code that was used in the working model of the buggy is written below. Group and I noticed that it was possible to look at other peoples code, and in reflection others could look at ours, through any followers on our blog. With that in mind, since the evaluation was completed this morning I am now putting on the code as my work could have been used for other buggies.

Richard bay and I created this code through joint effort on the circuitry.

symbol ledstate = b0

mainswitch:

high 1

debug

if pin7 = 1 then ' has button been pressed?
if ledstate = 0 then 'if it has then if we are off (ledstate = 0) then tell system we will
ledstate = 1 'want update the status so we know LED is on.
goto start2
else
ledstate = 0 'if on, then update status to off
goto start
endif
endif

if pin7 = 0 then
if ledstate = 1 then
goto start2
elseif ledstate = 0 then
goto start
endif
endif

GOTO mainswitch

start:

readadc 1, b1 'read the analogue values from
readadc 0, b2 'left LDR (b1), and right LDR (b2)

if b1 > 110 then 'This is allocates values to b3 and b4 depending
b3 = 1 'on the input coming from the LDR
else b3 = 0
end if

if b2 < b4 =" 1" b4 =" 0" b5 =" b4"> 140 then 'This is allocates values to b3 and b4 depending
b4 = 1 'on the input coming from the LDR
else b4 = 0
end if
if b2 > 120 then
b3 = 1
else b3 = 0
endif

b5 = b4 * 2 + b3 'Arithmic condition that will allow the PICAXE
'to decide whach case to choose.

select case b5

case 0
low 3
high 4
low 6
high 5

case 1
low 3
low 4
high 5
low 6
pause 5000
low 3
high 4
low 6
high 5
pause 3000
low 3
low 4
low 5
low 6

case 2
low 3
high 4
low 6
low 5
pause 5000
low 3
high 4
low 6
high 5
pause 3000
low 3
low 4
low 5
low 6

case 3
low 3
low 4
low 5
low 6
high 3
low 4
high 6
low 5
pause 2000

endselect

goto mainswitch

When the buggy was doing the track following set of commands (start sub routine) the LDR's were acting wuite strangely as one would increase and the other would decrease. We could see nothing wrong in the wiring of the system so we just altered the clause statements so that the appropiate case was chosen.

From the past lectures we had decided that a select case format was probably the simplest and safest choice to pick for a couple of reasons:
1) The program would be very easy to cnofigure and debug
2) It cut down on the amount of code needed to be executed for each repeat
3) Reduced that amount of places where confusion would arise.

Without the coding before the cases, where it gave b3 and b4 set values we would have had to create two different sets of cases which would have nearly doubled the processing time for each repeat. Also with the set up we designed if any problem s arose it was very easy to see where.

The design also worked for the instruction side of the assignment so a simple clone was made of the original code and then the cases were altered so that they followed set routines and did not simply repeat in a rapid fashion.

When it came to switching between the two sets of code, we decided that using the simple routine that was taught when looking at switches would work and whatever the value that was on ledstate would decide which subroutine the program would skip to.

Through the simulations the program worked as expected however in the real life result the coding was either running too fast for the buggy operation or too slow depending on what output was coming out of the weak motors, which were very unreliable.

Final amended circuit diagram

This is the final circuit diagram for our line following buggy. We have included a switch to enable switching between the two pragrams. One for simple line following and the other for the instruction set. We have used a pull-down configuration for the switch. There has also been an LED included as an ouput. This is to be placed between our two LDR's inside the skirt so that there is a constant stable light source to calibrate the two LDR's against. This minimises any effect ambient light could have.

The rest of the circuit remains unchanged.

Video of working circuit

This is a video of the working circuit.

We did have a few problems with the wiring where it wasn't downloading the code to the pic. So we decided to undo the wiring bit by bit to see where the problem was. First we got the LED's working, then the motors wired up, then the switch and finally the LED to show which program it was in.

On Monday the buggy will be assembled completely to test the code of the line following buggy.

Above the wiring can be seen. The wiring of board includes a switch, two motors, an LED and two LDR's.
The LDR's where wired 1st and have two variable resistors so that the sensitivity of the LDR's can be changed for the application. The switch is a pull up switch so that when it is not pressed the value into the pin is 0 and when it is pressed the voltage is pulled up to 5 volts in the pin. Both the switch and the LDR's are wired into the input side of the PIC and the LDR's are in pins 0 & 1 as these are analog inputs.
The motors are wired into the output side of the PIC and each motor is also wired into the darlington driver so that enough power can be created to drive the motors. Each motor has a resistor on the board so that a short isn't created. The LED is also wired into the output side of the motor and has a resistor so a short isn't created.
The wires from the board have been bent around the bread board so that the pic, darlington driver & battery pack can be rested ontop and the board can be flipped upside down for orientation.