Overall review of the whole project

Before saying anything about the project, I would like to say thank you to all my groupmates. At least, they did not kick me out of the group even I am stucked abroad for the most essential week.


On the project

We spilted this project into three area at the beginning. Programming, circuit and the physical components (wheels, gears, chassis). I was mainly involved in the program and the chassis bit.

Programming

Before Easter, Park and me started to draft the program. We break it down into parts. Basically, 4 functions are required. Power on/off, turn left/right, walk in stright line and reverse. We did some simulation in PICAXE but unfortunately I did not save it since that was the very first draft and that is it really before Easter.

Chassis

We disscused on this for kind of long because we have been changing our idea quite often before. Originally, I was about to bring a box-shaped chassis back. Well, the volcano in Iceland erupted. So, my fellow groupmate decided to get something better, meccano.



After all, it is such a shame that I could not take part in the assembling part, and again, I would like to thanks my groupmates. Althought it did not make it through the test, I can see we all learnt something from this project.

possible project improvements: personal opinion

If i were able to do this project again, i would change the following things;

• Power supply - As a group we found that at 4.5v, the buggy was vastly underpowered even with a light chassis.
• 2-pole DC motors - The motors supplied, basically lead to the demise of our project. we were under the assumption that all the contents of the toolkit were functioning 100% correctly, this was not the case. Some groups were having problems with the motors circuit, but both our motors had bad connections.
• Wheels - one of our wheels had a very large hole, meaning the axel and hole fit was too loose. this lead to the axel rotating, but the wheel remaining stationary.
  
• Planning - as a group we should have left more time for the atual testing of buggy, once constructed.

• Prioritising - the four main parts of this project were the chassis, program, circuitry, testing. we focused on the programming side for far too long, meaning the tasks were left till later.
  

I, personally have learned that priorty of each task is key to the success of the project overall. Meaning that it is no good having the best program in the world, if the circuit/chassis is not upto scratch. One thing i would not change if i were to do it all again is the group. This is because we all worked together fine and the communication level between us was very good, even if one group member was stuck abroad. Unlike my other project group (crane) where we are still yet to hear from one group member! he has neither shown up to any meetings or contacted us.

Project demonstration: reflection

This tuesday just gone our buggy was put through its 'test' aka demonstraion. photos and videos from the day will be upload soon including it actually working!
Over the holiday period, due to the icelandic ash caused by the volcano, our final chassis was stuck with our chassis designer in Hong Kong! This meant we had to create a new chassis before our circuit and program could be tested. Before and during the holiday period, as a group we were focussed on the programming and left the chassis till the end which in hindsight was definetly a bad idea (although who knew about the volcano problem prior to it errupting?).

TEST DAY
We had just completed everything by monday night, and we only needed to fine tune the chassis which we would have done on the day. 2 hours before the demonstration, our buggy had completly stoped working. this was due to one motor failing. During the duration of the project, we constantly had problems with the two motors which were supplied. We first thought there was a problem with our circuit, then we thought it could be the program and finally the sensors. The batteries were also replaced but with no luck.

After ruling all these out in the fault diagnosing process, we found that the cables connected to the reverse of the motors were to blame. It was due to a bad connection as if they were moved about, the cogs in the motor would 'flicker' into life.
As no replacement motors were available, we had to solder the wires to improve the connection. Fixing the actual problem was relatively fast once a soldering iron was sourced. The actual fault diagnosing was very time consuming. Once both motors were soldiered and the wires replaced, we encountered a short circuit. I am not sure how this could have happened but even the lecturer confirmed our suspicion.

Testing Of The buggy

Today we tested the buggy and it was not functioning at the time when we needed it to. It was functioning fine this morning, however, unfortunately i did not understand why the buggy was not even programming when we needed it to. The buggy may have short circuited as we were trying to fix the problematic motor once again.

Problem?

The problem in my view was the connection leading to the motor . We tried to solder it many times and as we pressed on the blue wired connection, the motor would start to run. We tried everything , however, i personally think the batteries were accidentally left connected when trying to solder. This may have short circuited the buggy as we were in a desperate rush to atleast get the buggy moving again just before the test.

What would be done differently if i was to do this project again ..
I would stick to simple circuitry like the one which we had to rebuilt to. I would leave a lot more time to test the buggy for following the line and would want do the connections for the wires as strong as possible the first time around.

What was suprising about the project ?

One definate thing i found suprising was how many times the buggy defunctions . This is what i would take into consideration in future project. Everyday there was something which was failing, if not one thing, it was another. It has been a true practical learning experience that theory in reality does not always compute.

Technical Problems / Improvements

Two LDR's were placed on either side of the black line. In our design, especially from the pictures of our design, if both read light, the buggy would go forward ( which can be seen from the programming aswell. If one read darkness, the buggy would turn. We got to test this out , however, the testing was cut short as we had a motor problem near the time of testing. However, When the LDR's were covered ( with paper) which can be seen from our buggy pictures posted earlier, the buggy did follow the line better. The LDR'S were paried with LED's . This was due to the fact that as the LED went over the black line, less light would be reflected to the LDR. Each LDR was paired with an LED and covered in black paper so that it had a control light setting. As the LED moved over the black line it would reflect less light into the LDR. An improvement to the system would be to have a third LDR as we originally planned which would always be exposed to darkness. This would have been the middle LDR and would have made sure out buggy would not have strayed off the line. In addition, more could have been done with the paper cover of the LDR's to stop light comming in. This could have been made more stylish and more effective, however, we found this was not possible due to our own lack of time management.

Funtioning Of The Chassis.

There were quite a few ups and downs in this project. The wheels were rotating and we could set the LDR's to follow the line. However, there seemed to be a fault with the right motor and we had to halt the testing of our buggy whilst following the line. We had to focus on the right motor. In this process, we did quite a few things to test the right motor. One of the things we did was to change the wires of the left motor with that of the right. The video of us doing this is shown below.

Changing of Wires

There was no result in the functioning of the right motor.

We also connected the wires to the actual motor to see if the motor was not damaged. The wheel at this point did rotate meaning it was something in the circuitry ( which we doubted ), or the connection of the wires was not strong via the soldering.

When we re soldered the wires to the right motor , it started to work. This stage can be seen in the video below.

Finally Working Again

We then connected the circuitry back up to the chassis to see if the power of the right motor was enough to drive the chassis forward again. The video of this can be seen below.

Moving Again

We can now finally configure the chassis to the right setting of the LDR's to make the buggy follow the line !

Hopefully you can all meet me tommorow so we can get this done.

Building & Development Of The Chassis

I thought it would be an easy task to build the chassis, however it was not as easy as seemed. This was due to the fact that the screws and bolts were very small and fidly. The progression when making the chassis was all recorded by taking pictures of the chassis at different stages. These can be seen below.


























I first started off by building the main body of the chassis which can be seen from the picture above. It seemed to be the strongest way of building the base.

































The progression of the chassis can be seen from above as i added a diagonal strip and attached it to the main body to give the circuitry some protection from falling out and this also made the body of the chassis stronger. The strip you can see at the front is for the rotation of the front wheel .

The two pictures above, show the completed body of the chassis without any of the circuitry and wheels. For extra presentability, a chair was added to the chassis above the block situated at the back of the chassis. The design proved to be strong when holding the circuitry and batteries. This can be seen in the picture below.

The picture above is the chassis holding the circuitry . A better effort could have been made for tidying up the wires on the chassis , however, greater this was not done as we had issues with making the chassis turn when following the line.

A clearer view of the wheels and the LDR's is presented in the picture above. We had to put a cover over the LDR's for their proper functioning and the chassis was following the line. However, unfortunately, one day before the date of testing, our right motor stopped working for some reason, which in my view was unfortunate as the buggy was functioning one day before the test. Also, the backwards slop of the buggy allowed the batter to sit under the circuitry and not move out of place. This can be seen in the picture above.

Completed Programming

main:


readadc 1, b1
readadc 2, b2

select case b1

case 78 to 255 ; LDR doesn't detect light
low 1
high 2
case 0 to 77 ; LDR detects light
high 1
low 2

end select

select case b2

case 60 to 255 ; LDR does not detect any light
low 3
high 4
case 0 to 59 ; LDR does detect light
high 3
low 4

end select

debug b1
debug b2

goto main

Completion of Circuitry

The old circuitry which was built by james worked, however, when trying to make the command system work with the circuitry, we found it hard. This was due to the fact that the circuitry had 3 LDR's and 3 LED's , and our command system was suited to 2 LDRS and 2 LED's . I could have modified the system, however i was more comfortable modifying the circuitry . Below is a picture of the circuitry which was made by James.

Old circuitry

Rebuilding Of Circuitry Using Lecture Notes .

I used the lecture notes to rebuild the circuitry as i found the lecture notes to give clear, easy step by step notes on how to power up the motors easily. I did this for one motor and then connected up the second motor by emulating the first one. The LDR's were connected up after the circuit was complete. I only used 2 LDR's this time and 2 LED's in the circuit.

New Circuitry ( Simple and a lot less complicated )

Pictures of the final circuitry will be given in later posts as we still may need to modify it slightly, example extending the LDR's under the chassis , however, the circuitry shown above was taken a picture of as i was coming near completion.

Meeting 3 ( 17/04 /2010)

Important aspects discussed in our meeting were :

• The chassis has been made and the circuitry is complete .
• The program nearly works with the circuitry but for some reason the chassis is not functioning the way we would want it to . There seems to be some sort of problem , hence over the next week we need to work together to see what the problem is and to make the chassis work .

Advanced Command system

The previous commands were working however, there was too much of a wait in between some stops. Hence i have modified the system to suite the circuit a bit better.

main:
readadc 1, b1
readadc 2, b2

select case b1

case 60 to 255
low 2
high 1
case 0 to 59
high 2
pause 600
low 1
end select

select case b2

case 60 to 255
low 4
pause 200
high 3
case 0 to 59
high 4
low 3
end select

debug b1
debug b2
goto main

Command Development

Although the previous command was tested, it did not work. Therefore it is important that we have a command which actually works. The command below has been tested and is a lot more realistic for the buggy design in accordance to our circuit. It consists of case statements and is not too long !

main:
readadc 1, b1
readadc 2, b2

select case b1

case 60 to 255

low 2
high 1
case 0 to 59
high 2
wait 3
low 1
end select

select case b2

case 60 to 255
low 4
wait 3
high 3

case 0 to 59

high 4
low 3
end select

debug b1
debug b2
goto main

As you can see, there are onloy 2 case statements. One for one LDR and the other is for the second one. The circuitry has 3 LDR , therefore, the circuitry either needs to be modified , or the command need to be modified .

Full view of circuitry

This is a photo showing the full circuitry, including the motor and the control boards, before the changes were made to give our final circuit.

Photos of the circuit

Here are some photos of various parts of the circuit.

This is the control board with the various inputs and outputs connected.

We used different colours to try to make the circuit easier to create.

This is a photo showing the LDR's on the top, with some LED's wich we decided to remove, and possibly add in later, if we needed them:

We altered the resistors to 100K ohms to help ensure the circuit worked as we wanted it to.

Circuit Diagram

This is an older circuit, which we altered, to try and make more simple.

We decided to try to alter the circuit so we only had two LDR's, for simplicity in the programming, and so that there would be less that could go wrong.

The switch connected to pin 7 is the selector switch.

The LDR's had to be connected to pins 0,1,2 because they are the analogue pins, which were needed to read the signal from the LDR's. Pin 7 is a digital input. As shown, the motor board is the same as the other diagram, just drawn differently.

Photos of the motor board

Here are two photos showing the motor board, as shown in the circuit diagram.
The top two blue lines on each sides are connected to the motors.
The bottom red and yellow on the left are the positive and ground rails respectively.
The green lines below the motor lines are the enable lines, 3rd down on each side.
The two remaining on each sides are from the output of the chip which control the motors direction

Body Of the chassis

Although the chassis made out of a container would be ok, i thought it would be a better idea to make the chassis out of something a bit more sophisticated. ...... meccano!

Here is the exact set i am getting to build the chassis ! I will make it just right for the circuitry and we should be making the chassis work very soon !

Resistor reference chart

This is the resistor reference chart i drew up, to easily tell the value of a resistor.

For example, a typical resistor of:

Red Red Brown Silver

would have a value of:

220 ohms with a tolerance of 10% about that value

Initial command

symbol switchstate = input7
main:
switchstate = pin1
debug switchstate
goto work1
if input7 is on then work1
end
work1:
if input1 is on and input2 is on and input6 is on then go_f
if input2 is on and input1 is on then go_l
if input6 is on and input1 is on then go_r
goto go_s
go_f: let pins = %10100000
goto main
go_l: let pins = 100000
goto main
go_r: let pins = %10000000
goto main
go_s: let pins = %01000000
goto main

picaxe command

PICAXE Commands (valid all sizes):
Output - high, low, toggle, pulsout, let pins = Please see the BASIC Commands (v3.5)
Input - if…(and/or)...then, readadc, pulsin, button help file for more detailed syntax help
Sound - sound and information about each command.
Serial - serin, serout
Program Flow - goto, gosub, return, branch
Loops - for…next
Mathematics - let… (+, -, *, **, /, //, max, min, &, |, ^, &/, |/, ^/ )
Variables - if...then, random, lookdown, lookup
Data memory - eeprom, write, read
Delays - pause, wait, nap, sleep, end
Miscellaneous - symbol, debug

Light Dependant Resistors

A light dependant resistor (LDR), is an analogue sensor which detects light and changes resistance accordingly. Versions can be bought where the resistance either increases with light, or dark.
They would work in this project by detecting the contrast between the light background and the dark strip the buggy hass to follow.

Typical dimensions are shown on the diagram.

Reed Switches

A reed switch is a sealed glass tube, with two contacts inside it. It is a magnetic switch, either open or closed. When a magnetic field is applied to the component, the two contacts attract, and close the switch. When the field is removed, the natural spring in the contacts forces them apart again.

Typical dimensions are 10- 15mm in length and around 2.2mm diameter, not including the connecting legs

If a magnetic field strong enough to operate them cannot be guaranteed, they cannot work

Meeting 2 ( 22/04/10)

Today the group has come together to discuss how to create the chassis . The circuitry has been made however, the program is still being created and is nearly finished. Therefore, by the time of our next meeting, we have to :

• Create the chassis whilst making sure there is enough space for the circuitry.
• Complete the program , even if the buggy does not fully work yet!

Autonomous Vehicles - Land , Sea & Air.

Short Examples of projects or products which have the incorporation of autonomous technology in air , Sea and Land are given below.


Air

This project and research started in southern california in 1991 with the creation of the autonomous flying vehicle project and is still in operation until this very day. A succession of flying vehicles were made from the AFV ( Autonomous Flying Vehicle ) in 1991 which can be seen above to the AVATAR ( Autonomous Vehicle Aerial Tracking and Retrieval ) which was created in 1994.

Sea

The development of Indias first Autonomous Under Water Vehicle is expected to complete its final underwater trial by august 2010 . Autonomous Underwater technology is vigorously persued in many technologically advanced countires such as australia, germany, russia, korea and japan.

The creation - ' AUV 150 ' is a cylinderical carrier which is imbedded with advanced power, propulsion, navigation and control systems. Two arrays of cross fins have also been fixed at the two ends to provide additional stability to the AUV. A lithium plymer battery powers the vehicle and a pressure hull contains its electronics and energy system. The vehicle can be seen below.
































The use of the vehicle is to carry out an underwater mission without assistance from an operator on the surface. The vehicle determines its own geographical position with navigational sensors .



Land

The audi pikes peek TTS Autonomous vehicle which also has been given the nickname shelley is an autonomous vehicle capable ot completing the pikes peak international hill climb in a reasonable time using rally driving techniques.

The main team behind this operation was the volkswagen electronic research lab signifying that control systems within companies is playing a greater role in todays real world applications.

Autonomous Vehicles

An autonomous Vehicle is the type of vehicle that drives on its own. They are currently being devoloped by companies and universities all over the world !

Autonomous vehicle control uses external sensors of the environment to navigate or carry out a particular task. This is different to normal vehicles which demand an input to carry out a set job.

The use of such vehicles can reduce costs and has other advantages. Doing repetetive tasks manually can require certain costs hence more labour. However, the advantage of utilizing the autonomous vehicle is that the tasks would not need to be supervised ( safety ) and can be done over and over again without the vehicle 'getting tired'. This can lead to greater efficiency.

Recently the concept of such a vehicle has flourished into the control engineering sector and the expansion of such vehicles on air, land and sea may shape the future of many engineering concepts which are used today.

comparing

' PICAXE-18X TPIC6259
'
' Output5 (term 11) ----------------- /G (term 13)
' Output4 (term 10) ----------------- CLR (term 19)
' Output3 (term 9) ------------------ D (term 18)
'
' Output2 (term 8) ------------------ S2 (term 12)
' Output1 (term 7) ------------------ S1 (term 8)
' Output0 (term 6) ------------------ S0 (term 3)
'
' Uses about 128 bytes and could probably be accommodated in a less expensive
' PICAXE-18A.

initial programme using LDR

it is so rough one. we need to develop this programme.
Basically using the LDR and check the value.
given the condition as below
the picaxe read a light sensor measure (sensor 0) and show measures from 0 to 250, but if we suppose that 0 is 0% and 250 is 100% (presence of light)



LDR value 0 to 250 it will show 0 to 100%, also shows number of readings taken, it reads the LDR once per second.

Percentage = ldr * 100 / totalvalue

#picaxe 18x
symbol Percentage = b0
symbol ldr = b1
symbol Readings = b2 
symbol TotalValue = 250

Readings=0
serout 7,n2400,(254,1)
pause 30
do
readadc 1, ldr
percentage = ldr * 100 / TotalValue
inc Readings
serout 7,n2400,(254,128,"Reading #",#Readings)
pause 30
serout 7,n2400,(254,192,"Light = ",#Percentage,"% ") 
pause 1000
loop 

Outer shell idea

instead of having our robot looking simillar to this....

i was thinking of using one of these as i can get hold of one....
the dimenisions are ~42cm by 20cm which will easily fit all the circuitry and controllers etc.
just need to source a suitible material for the base as i dont think it will be supplied...

chassis - intial findings

As we have not chosen a sensor type, it is hard to actually design the chassis but we have been looking into the following ideas

2 large wheels mounted towards the rear of the buggy, with one small (non-powered) wheel at the front. Similar design to the Robin Reliant (but more stable!).

OR

2 large wheels mounted at each side (centre).

OR

even two large wheels towards the front of the chassis and one small wheel at the rear. this small wheel could act as a 'rudder' like on a boat.

Sensor type research

(WEEK 1 WORK LATE POST!)
As a group, we have narrowed the down the possible sensors we can use for the robot.

Miniature Reed switches - (Magnetic sensor) still not sure whether the supplied sensors are up to the job, so we will be carrying out further testing in due course. If we can get this to work then the programming side of things will be easier (no ADC required etc). May also have to purchase strong type of sensor (more sensitive).

L.D.R - widley used and 'tried and tested' in L.F.R's so there is a lot of reasearch available.

INFRA RED - use of these sensors will result in a relatively easy circuit, but in the majority of the cases LDRs are preffered.

Optical sensors - again we will have to look into this aswell, but having seen them in action, i am very impressed.

simple programing

POSTED ON BEHALF OF JUNGKYOO PARK
This is a simple type of command.
It shows how to follow a line. It is really simple program using no speed control.

init: pause 1000

main:
if b1 is on then go_f ‘ forward
if b2 is on then go_l ‘ left
if b6 is on then go_r ‘ right
goto go_s ‘ stop as no line nearby
go_f: let pins = %10100000 ‘ go forward
goto main
go_l: let pins = 100000 ‘ go left
goto main
go_r: let pins = %10000000 ‘ go right
goto main
go_s:
let pins = 000000 ‘ stop - not line anymore
goto main

meeting 1 ( 14 /03/ 2010)

The group has come together to discuss how to go about making the commands on the pixace program.

Points made were

• The program should be made using case statements as it is something we are familiar with
• Whilst the program is being made, james would make the circuitry .

Just two basic steps are being taken this week towards the project .

Gantt Chart

On the initial group meeting , this gantt chart was designed to assign different members of the team with different tasks to be completed at specific dates.

Project launch

Team list:

Kaiho Sy
Jungkyoo Park
Shazad Hussain
James Woods
Romi Dhillon

3 mar 2010