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.

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