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.

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.

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.

• 
  

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.

Case Statements

The following flowchart code is being considered; utilising case statements to direct the robot:

Let b0 = pins
let b1 = 000111 & pins
select b1
case = 000000; both motors off and return to select
case = 000001; Right hand motor on and return to select
case = 000010; both motors on and return to select
case = 000011; Right hand motor on and return to select
case = 000100; Left hand motor on and return to select
case = 000101; Error
case = 000110; Left hand motor on and return to select
case = 000111; both motors on and return to select


The individual case (ie how to drive both motors will be developed in a later blog).

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

Group Research - Human Factors and concerns with UAV's.

The following link from S. McCarley & C.D. Wickens(1), et al,highlights the main issues identified in this area. To summarise they are:
1. Displays and Controls.
2. Automation and System Failures.
3. Crew Composition, Selection and Training.

To add an interesting addition to the automation category however, at what level of automation should a human decision be compulsory. Is it okay for an UAV to decide to destroy a high profile military target at cost to civilian life/infrastructure?


(1) McCarley S.J. & Wickens C.D. (2005)
HUMAN FACTORS CONCERNS IN UAV FLIGHT
Institute of Aviation, Aviation Human Factors Division
University of Illinois at Urbana-Champaign

Progress report - 15/3/10 - Ian Thomas

The following issues were discussed in the classroom session (15/3/10):

Type of Design -
4 Wheels. Harder to setup - Unnecessarily so.
2 Wheels. Unless perfectly balanced it would be likely to drag - this was seen as an unprofessional approach.
3 Wheels. Manouevrable and reasonably easy to construct, if not the most original design.
Tracked. Good manouevrability but complicated to construct and needs specific parts.
Hover craft. Too complicated with a lack of manouevrability.

The group decided to analyse a 3 wheeled design and a tracked design further.
TRACKED - Luke Hildred to investigate available track parts.
3 WHEELED - Excellent control. Favourite of the group.

Sensor Choice -
MAGNETIC - Reed switches (Requires further investigation and testing). The less sensitive switch provided in class isn't up to the task - Duncan Scriven to investigate other options.
INFRA RED - Cheap and effective in the right conditions. Lots of online reviews have recommended that these aren't used so the group have decided to forget using them).
LDR - Cheap and effective with extensive research readily available.

Gantt Chart, Ian Thomas

I have created a Gantt Chart to track the progress of the group and make the allocation of tasks easier. It cannot be uploaded to this blog; so it will be utilised at the classroom session each week. All group members will receive an up to date copy each Tuesday; where new tasks will be agreed and documented.