Some Initial Programming

A quick bit of programming to see if the buggy was working once constructed:

Sensor Input Program:

main:
READADC 0,B0
READADC 1,B1
READADC 2,B2

Debug

If b0>100 then b3=1


GOTO main:

Motor Test Program:

Main:

High 0 `Run Motor 1(?) Forwards(?)
Low 1
Pause 3000 `Pause for 3000
Low 0

High 2 `Run Motor 2(?) Forwards(?)
Low 3
Pause 3000 `Pause for 3000
Low 2

Goto Main:

Initial Buggy Program Idea:

Main:

Read 0,B0 `Left Sensor written to Bo
Read 1,B1 `Sensor 2 Written to B1
Read 2,B2 `Right. Sensor written to b2

Low 5 Low 4 Low 6 Low 7

Debug `To check working correctly

If B0=1 Then high 5 Low 4

Else If B2=1 Then high 6 low 7

Endif
Goto Main

Evolution Of Buggy

Testing day

Once all of the programming, building and debugging had been completed it was test day. The first thing on test day was to set the robot to the ambient light conditions experienced in the room which meant changing the program slightly to accommodate for this. Redo any last adjustments and then our line follower was off. Having came to Test day we still realised we needed to have a lot more debugging process ,the motors did not produce enough torque, one of the circuits driving the motor board was not working correctly as one of the motors would not go backwards (not a problem for line follower mode but for symbol mode it was).

Our tests went significantly better then the Marked test from the lecturer , our robot managed to sense the line but it did not have enough torque to turn. And on the symbol mode our robot managed to only recognise the Left and Right turn but the action that they performed was not 90 degrees left and right , instead they just continually span round.

Programming

The final programming had been completed. The main areas and problems associated with programming are as follows.

• How to read the inputs effectively, especially as we were reading in ADC inputs and how to convert them again into a binary form , so case statements could be used. We managed to do this through reading each of the inputs into a memory location . Then using If statements these could be analysed and if over a certain value a 1 , 2 ,or 4, which in binary is 001 , 010, 100 could be added to a separate memory location , in my case b3. E.G if my left sensor sensed the line and went past a certain value then in b3 would be 100, if my right 001 and middle 010 or any combination of theses , like if all sensed the line 111. With this case statements could be used. It is important however after selecting the case to erase all the values in b3 so when the programs loops the values do not keep adding up.
• How to change between modes, symbol mode and line follower. As we used a toggle switch which was connected to input pin 7 , we just read in all the pins to a memory location and if over a certain value (because pin7 if on would effectively have a value of 128, and thus make any values being read into the input pins over 128) then it would be in symbol mode and if under the value it would be in line follower mode.
• Lack of program memory, it was soon realised after creating my program that the computer would not allow it to download onto the chip because the program took up to much memory, essentially my programming for the motors which I put into each case was making the file way to big. The way I combated this was to use subroutines. I made one for forward , turn right and turn left. These could be called by using GOSUB...turnright and the program would return to its original location by use of the command RETURN. This saved duplicating lots of code, and made my file size much smaller.

The finished program was as follows;

main:

b7=pins ;read in all pins to memory

readadc 0,b0 ;reading all adc inputs to memory

readadc 1,b1

readadc 2,b2

if b7 <10>

goto symmode ;else go to symbol mode

normal:

if b2>100 then let B3=B3+1 ;right sensor, p

endif

if b1>100 then let B3=B3+2 ; middle sensor

end if

if b0>100 then let B3=B3+4 ; left sensor

endif

select B3 ; case statements for the different scenarios

case %00000000; both motors off and return to select

case %00000001 ; right motor off

gosub turnright

case %00000010 ; both motors on and return to select

gosub forward

case %00000011 ; Right motor off

gosub turnright

case %00000100 ; Left hand motor off

gosub turnleft

case %00000101 ; Error, carry on

case %00000110 ; Left hand motor off

gosub turnleft

case %00000111 ; both motors on and return to select

gosub goforward

end select

debug

let b3=%00000000

goto main

symmode:

if b2>100 then let B3=B3+1 ;right sensor

endif

if b1>100 then let B3=B3+2 ; middle sensor

end if

if b0>100 then let B3=B3+4 ; left sensor

endif

select b3

case %00000000 ; straight

gosub goforward

case %00000001 ; forward 90 right

gosub turnright

pause 1000

case %00000010 ; straight

gosub goforward

case %00000011 ; forward 90 right

gosub turnright

pause 1000

case %00000100 ; forward 90 left

gosub turnleft

pause 1000

case %00000101 ; Forward pause reverse

case %00000110 ; Forward 90 left

gosub turnleft

pause 1000

case %00000111 ; Forward pause reverse

end select

debug

let b3=%00000000

goto main

turnright: ; subroutines for driving motors

`To Turn Right

High 5 `Left Motor Fowards

Low 4 `Left Motor Forwards

low 6 `Turn Right Motor Off

return

turnleft:

` To Turn Left

High 6 `Right Motor Forwards

low 7 `Right Motor Forwards

low 5 `Tur Left Motor off

return

goforward:

`To Drive Motor Forwards

High 5 `Left Motor Fowards

Low 4 `Left Motor Forwards

High 6 `Right Motor Forwards

low 7 `Right Motor Forwards

return

Group feedback and product development.

After the testing of the product resulted in it failing two tests, and only completing the main line following task with a little prod now and again, the group have decided that implementing the following steps would help produce a successful design:

1. Supply a greater voltage to the motors. This could be done by either using the 9V battery, the connection to the motor being controlled by a seperate motor board circuit, or running a further voltage source in parallel with the current supply; maintaining the voltage (4.5V) but increasing the current supply to the motors. This extra step would increase the torque of the motors.
2. Introduce a gearing system to the drive mechanisms. This would allow the buggy to travel at a slower speed, giving the LDR's plenty of time to sense changes in the road conditions and corrective conditions to be implemented appropriately.
3. Change the jockey wheel. The existing jockey wheel would often be mis-aligned when the buggy would try to change its direction of drive; the friction produced fighting against the motors. The installation of two jockey wheels, one in each rear corner, would elimainate this problem and allow the buggy to move more easily.

Fault Diagnosis

Upon finding the motor circuit was not operating correctly it was decided to trace the fault; so that appropriate action could be taken.
1. Using a continuity tester all the PCB was tested to ensure that no solder had 'tracked' across between lines. Only one case was found and quickly rectified but did not resolve the fault.
2. Using a voltmeter all voltages were inspected. Starting at the main battery pack and traced successfully to the motor circuit board. All voltages entering the motor circuit board were correct but the expected voltages that should have been seen on the motor terminals were not there. This suggests that there is a fault with the motor chip; which willneed replacing.

Final Design

The final and new buggy has been made as a team this weekend. Its chassis built from Durable modelling plastic ,and all the circuit boards soldered up nice and neatly. The jockey wheel has been far improved, and the whole buggy moves in a straight line and does not veer off to one side. The new Sensor array has been made with 4 White LEDS and 3 LDR's placed underneath the vehicle. With testing these appear to work really well giving constant values untill a black line is moved underneath them. However during Testing the motor circuit board has not been working this could either be a fault with the circuit or a blown motor chip.

• 
  

A second prototype has been constructed and a few changes have been made. The chassis design has been altered slightly. A plastic container has been used, which has had holes drilled to allow mounting points for both the motors at the front and the jockey wheel at the rear of the buggy. The buggy appears to be able to move straight, left and right, however it only appears to do this while the jockey wheel is mounted at the back of the vehicle, hence why they are that way round. The new motors are a definent improvement, now that they aren't buckled. Additional improvements that can be made are as follows:

- A more stable jockey wheel.
- A better chassis for the buggy to sit in.

After a lengthy group meeting today, we have decided on a few more changes for the buggy as a whole.

- The inner circuitry will be redone and neatened.
- The inner circuitry will be mounted on a semi-removable board for aesthetics and practicality.
- The jockey wheel is to be reconstructed.

Electronics

The electronic circuit has been built as follows from the circuit diagram (Courtesy of Duncan Scriven), currently it resided on a bread board but will eventually be put on a circuit board to aid in weight reduction.The sensor and provisional LED array have also been made. This includes having 3 LDR's evenly spaced 0 0 0 and an ultra bright LED placed next to them to give light (as mentioned earlier more LEDs can be used. (The LED circuit for now has been made seperate to the motor circuit as to not drain the batteries but it can be attached to a pin.) After Testing the sensor array it became apparant that different ambient lighting affected the sesnor array so my sensor array will need to be completely enclosed so as the only light reaching the LDR will be coming from the LED's. It also became apparant that using just digital inputs was a bad idea having to manually change them when the lighting conditions continually change, so we have changed to reading the ADC output of each of the pins keeping the potentiometers at one level.

First prototype.

The first prototype has been constructed. The group decided to base the design on a three wheeled basis, whereby the chassis was to be made out of plastic containers, to give rigidity and light weight. The use of the original wheels and motors help as we know these can be run effectively without too much complication. Despite this Some major problems have surfaced as a result.

• One of the worm gears is not straight and so will have to be replaced.
• There is a distinct lack of speed and manoeuvrability, however it is still able to run , so placing weight nearer the motors may help , especially when turning.
• As the group decided against lego and other "toys" as this does not show originality, the body had to be made ourselves. This is slightly tedious as nothing will fit tightly , however with the use of drills this situation is being remidied.
• Trying to find an appropriate jockey wheel that can fit with the chassis effectively and to which is effecting the turning. At the moment a lego jockey wheel has been constructed but is ideally not suitable.

Programming limitations

As the PICAXE only has 5 inputs , and one input must be used to switch the mode of the LFR from line following to symbol recognition, the amount of sensors we planned must be reduced. We are now reducing the sensors to 3 . This is beacuse when we read pins (all the input pins) these are neatly together at the end of the byte (bit 0, bit 1 , bit2) relating to (pin 0 , 1 ,2) so will be easy to program, and there will only have to be 8 different cases. Pin 6 or 7 will have to be tied down and one used for the switch. The only down side to this is that the buggy wont be able to adjust so precisely as it could with more sensors.

IF/ELSE Case Statements

As part of the development of the programming we investigated using the following If/Else flowchart. Eventually we decided against it as it is better programming etiquette to use Case Statements to achieve the same aim.

Let b0 = pins
Debug Pins; This command would indicate what the device 'thinks' to the observer
let b1 = 000111 & pins
If b1 = % 00000000; No Action
Else b1 = 000001; Hard right turn
Else b1 = 000010; Continue straight
Else b1 = 000011; Gentle right turn
Else b1 = 000100; Hard left turn
Else b1 = 000101; Error.
Else b1 = 000110; gentle left trun
Else b1 = 000111; Continue straight

Programming

The following is how i want my programming of the LFR to pan out. The 1's are when my sensor has sensed the line and my O's for when it hasn't. In effect with 5 sensors there are only 32 combinations (binary) that need to be accounted for in my program.

00000- No line stand still.

00001- Hard right

00010-Gentle right

00011-Gentle right

00100-On track keep forward

00101- Error keep on current trajectory

00110-Keep on trajectory

00111-Hard right (corner)

01000-Gentle left

01001-Error

01010-error

01011-error

01100-keep on trajectory

01101-error

01110-hard left (corner)

01111-hard left (corner)

10000-hard left

10001-error

10010-error

10011-error

10100-error

10101-error

10110-error

10111-error

11000-Gentle left

11001-error

11010-error

11011-error

11100-Hard Left.

11101-error

11110-hard left

11111-Stop

I now need to decide weather it is best to use interrupts or not. They would be faster , however, and would allow code to continue uniterrupted untill a corner or deviation from the line would be detected. However my lack of knowledge on programming interrupts in PICAXE Basic will need to be enlarged as it has not been covered in great detail.

Autonomous Robots- Industrial andDomestic

Autonomous robots (Picture courtesy of KUKA Robotics) and vehicles are machines that are capable of interacting with the enviroment through use of sensors and programming. In effect they are "Intelligent" in the way they need little human contact, to carry put they're desired tasks.

The different sensors can sense many different things, some ,like humans, sense heat, light,sound, touch but as sensors are so varied , robots can sense atititude , latitude and longitude, UV, Infra red and react accordingly with what they find. Some intelligent robots , using cameras can sense depth of vision and objects that may come in its path. In industry Autonomous robots can be used in factories for producing goods, the classical use for industrial robots was to just work on a cordinate system, e.g. Place screw A at 10cm Screw B at 5 cm, but new developments mean that robots can sense the object they are working on. This can allow for less errors and smarter robotics that can adapt if the object it it working on is not entirely perfect, or it can handle different objects at different times without having to be reprogrammed completely. This ultimately reduces cost. One example is for using robots to pick up parts from conveyor systems, which can be an expensive task with "unintelligent robots" by use of "2-D vision" cameras can locate different parts and are able to control an arm to pick up said parts.

As ever ,after industry , domestic autonomous robots have come into use. Irobot has been developed to deal with domestic vacuuming. Its sensors detect when objects are in its way, what floor conditions it is travelling onto, and it can even detect its base station , so can recharge itself when its batteries are low. The way in which it can negotiate obstacles is interesting, in this case it is randomness , the cleaner robot will try many different approaches until it finds one which can work "randomness", whilst some more expensive military robots can create a map of the future surroundings by use of its sensors , building up a picture through which it can navigate easily through. The Vacuum cleaning robot can even find its base station to automatically charge from, with the base station emitting an infra red signal with which the robot can follow, which is a way of "foraging" just like humans do for resources. (Video courtesy of Irobot corporation)

Programming and Limitations

Before we start programming we need to know the limitations of the PICAXE board.It can only store 14 variables and has only 5 inputs(of which only 3 are ADC) and 8 outputs that can transfer useful data. We also need to know the amount of sensors and the configuration these sensors are in . Through looking at research, 2 sensor layouts are domianant, an inline configuartion or a upside down V configuration.

O O O O O -Inline

O

O O

O O - Upside down V

The advantages of an upside down V become apparent if ,on a course ,there is more than a 90 Degree turn. (Which on the course this robot is going on there wont be). However I believe that in-line sensors are good enough , and make it much more simple to program. Having researched how the line follower will work I prepared these diagrams, that will explain further the movement of the robot whilst following a line and the the sensor configuration and how it will work.

Practically using sensors i can determine position on the line and can start preparing Programming flow diagrams, however these will be quick to change in the debugging process once the rest of the robot is built.

Research-Sensors

One of the biggest decisions in the project is what sensors to use.Initial research on sensor types suggests there are 3 primary sensor types we can use , which include reed switches , LDR's and IR sensors. The following pictures show the pros and cons of each sensor type.

LFR (Line following robot)- Initial ideas