Motor Subsystem;

 After Laying out the circuit diagram and the connections to the various outputs,   we needed small sections of  programming routine so that when  the programmer came to assemble the final developed program,  small sections of code  could be copied and pasted in.

Firstly, we had to devise a code to check that the motor were wired up correctly and that it would turn backwards and forward.

Main:
    low 1        `Drive the motor forward
    high 2
    pause 5000    `Pause for 5 seconds
    high 1    `Drive the motor backwards
    low 2
    pause 5000    `Pause for 5 seconds
goto main        `loop to start

Once this was working, the code was copied and  applied to 2 motors to make sure that they both worked;
 This routine was called "goforward" (obviously)

`To Drive Motor Forwards
High 5    `Left Motor Fowards
Low 4     `Left Motor Forwards
High 6    `Right Motor Forwards
low 7        `Right Motor Forwards

(Note the change in Pins, as this code was run on the fully assembled buggy, whereas the first code was run during  the lab sessions during the first couple of weeks)

Once  we had this  code and sub-system working,  we were able to play around witht the outputs of the chip to create smaller subsections of programming that would enable the buggy to  turn left and right. Here are the devised codes;
turnright:

    `To Turn Right
High 5    `Left Motor Fowards
Low 4     `Left Motor Forwards
`Code To Turn right Motor Backwards
Low 6
High 7
return

 And the code to turn left;

turnleft:
` To Turn Left
High 6    `Right Motor Forwards
low 7        `Right Motor Forwards
`Code to run Left Motor Backwards
Low 5
High 4



These blocks of text where then substituted in to the Alecs program.

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.

Development and Progression

The final few days of development have seen a big rise in the level of activity surrounding the buggy. The group have worked hard to develop a well built, professional product that meets all the aims; with numerous problems arising. These problems have seriously hindered progress but have resulted in a better quality product being created.
The problems were:
1. Motor Power. The motors do not have the torque to turn the chassis (which still appears to be relatively light) upon command.
2. Motor driver board problems. Fault diagnosis suggested that the motor driver board was faulty (a blown chip was suspected), but after creating a new resistor board the fault was found to be in the input voltage to the system (the batteries!).
3. LDR sensitivity. As the suspected fault with the motor driver board briefly stopped development of the moving parts, the group focused their attention onto developing the sensing elements. The LDR's and LED's were mounted onto the front of the buggy at a sensible height to allow adjustment; once testing commenced. Upon reflection it was realised taht the variable conditions experienced in the actual testing laboratory (Room 160 in Aston university) were vastly different to a dimly lit basement.
4. Available products/parts. The supplier used to precure all the components and parts had run out of the LED's that were used to provide a more stable light source for the LDR's to detect. This resulted in a change of LED - a solution that quickly enabled testing to get back on track.