IB Integrated Design Project
Final Report


HTML version. For the Word version click here.

Sam Blackburn, Girton College

View all the photos of the robot here

CONTENTS

  Page (on printed version)
Introduction. 2
Project management. 3
Conceptual Design. 4
Development. 5
Choices of Circuits. 6
Problems Encountered. 7
Integration and Testing. 8
Robot performance. 8
Conclusions and Recommendations. 9
1st report. Appendix 1
Overall Circuit diagram. Appendix 2
Connection Diagram. Appendix 3
Parts List. Appendix 4
PCB layouts. Appendix 5

INTRODUCTION


The IDP is about working in a team to build a robot. The robot must collect fittings (which are about 10cm in size) from a collection area and measure their temperature, sorting different temperature fittings into different bins.

Our entry was working well: fairly reliable and fast enough to move all five fittings in the required time, mostly because we had made a working robot quickly enough to allow plenty of time to iron out any problems.
Everything stopped going well 30 seconds into the test. The robot suddenly began to spin around and move at random. Because we had to hand the robot in, we have no idea what caused this, but our software team's code is almost certainly not the problem. Given more time, we could investigate!

This project has been enjoyable and valuable. We did produce a good robot, it's a shame that it couldn't perform and annoying that we don't know why.

PROJECT MANAGEMENT


Because of the restrictions on the parts we can use, there is relatively little interaction between the sub-teams once they have decided on what signals are necessary. All the green boxes below are parts that are given to us and we only have to decide how we will use these parts before we can design each blue box separately.



The software designers will have requirements (e.g. "4 devices, positioned in a straight line x cm from the wheelbase and y cm apart, that detect lines and drive bits 0-3.") The electrical and mechanical designers should be able to work around these requirements, provided that the devices needed are available as defined by the given boxes.

Timetabling threw up some problems. I proposed the timetable on below, but the mechanical team said that they couldn't build the chassis that quickly, so we went with their plan, which proposed no construction until all design work was complete. The result was that the software team had less time to test their code on a moving vehicle, but more time with the completed robot, since the arm assembly was completed more quickly.
Day Thur Tue Wed Thur Tue Wed Thur Tue Wed Thur Tue Wed Thur Tue Wed
Week 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5
Mechanical Sub-team Abstraction, delegation Conceptual Design Agreement upon interfaces Function Design Design and build chassis + drive Assemble moving vehicle Design and build lift and grab functions Assemble complete robot Go to Pub Test complete robot, catch up

Evaluate
Electrical sub-team Function Design Make sensors + motors functional Build rest of circuits
Software sub-team Function Design Go Shopping Test and debug navigation code Test and debug Kenny handling code

CONCEPTUAL DESIGN

The problem was first broken down into functions: Lift, Carry, Drop and Recover. These are really just two functions plus their inverses: Lift/Drop and Carry/Return.

The lift/drop function can be broken down further: something must move vertically if the Kenny is to be lifted, which suggests a moving arm of some sort, and something must engage the Kenny. We thought of putting a spike through the fitting and lifting it, but decided that the accuracy of the robot would not be sufficient to aim reliably for the hole. If the skewer missed the hole, it would knock the Kenny over and we would have to manually intervene. We decided on jaws instead, one fixed and one moving for greater simplicity. They should be able to pick the fitting up in almost any orientation so knocking it over is not a problem.




The carry/return function is conceptually simpler but requires far more complex control, for example it must make use of feedback. Motors and wheels form the only sensible method of moving the robot using the given components, and 2 driven wheels are clearly the simplest mechanism to turn the vehicle.

The control system needs to sense the robot's position and ideally orientation somehow, and we are given infrared line sensors and micro-switches for this purpose. The control system will benefit from plenty of testing on a working model, so a chassis with working sensors and motors would be useful as early on as possible in the project.

DEVELOPMENT

One of my ideas for the lifting function was to tilt the entire robot, either by accelerating very hard using the drive motors or by moving a mass, to overbalance it. The mass could be pushed backwards by a pneumatic ram, lifting the fitting. However, this idea fell apart when we worked out that we would need a 50° tilt angle to lift it over the wall of the bin before placing it there.
The mechanical team decided to use a chassis that stayed horizontal so that the line sensors would stay close enough to the lines. They attached a moving platform that was tilted by a pneumatic ram. The arm, fixed to the moving platform, had jaws on the other end. The microprocessor was, as initially planned, mounted on the moving platform, but it turned out to be easier if the moving platform was made relatively small. On the final version, the microprocessor sits on the static frame and the moving frame is simply part of the arm.

CHOICES OF CIRCUITS

There are 4 circuits that need to be produced. Each have connections to the microprocessor and to the power supply, but do not interact with each other, so they can be considered separately as long as we keep an eye on the total current consumption.

1. The line detector: The only sensible way to do this is with the supplied infrared sensors. A beam is sent from an infrared LED and any reflections from white lines will trigger a phototransistor in the same module. One danger is that of crosstalk, where light from one emitter is scattered and triggers several detectors. Switching on only one emitter at a time is the easiest way to solve this problem, as erroneously triggered sensors will be ignored by the microprocessor.
Testing the modules, using the supplied test box, showed that the line detection only worked if the module was close to the ground - about 3-5mm away. The greatest tolerance for this height was found when the maximum allowable current (35mA) flowed through the source and the maximum resistance was used in series with the detector.
Our initial design used 4 output and 4 input pins. The output pins were driving the emitters (via buffers) and the detectors formed potential dividers with resistors, driving inverters to send logic signals to the inputs. There were also indicator LEDs on the outputs of all buffers and inverters, which would run at the maximum forward current (20mA).
Maximum current: 220mA.

2. Temperature sensor: The two viable options are a thermistor or a thermocouple. There isn't a great deal to choose between them, as either can detect changes in temperature. One difference is that the thermocouple measures temperature differences, but the most of the robot is at constant temperature during the test anyway so this still a reliable method.
A dual comparator circuit is shown in section E.A.6 in the blue book. I exchanged the fixed reference levels for potentiometers to allow easy adjustment of threshold voltages, and added a thermocouple between a potential divider and the input to the circuit, so that the input was slightly above/below half the supply voltage depending on temperature. With the potentiometers set correctly, this should discriminate between the three temperatures.
An indicator LED sits at each output from the comparator to aid calibration.
Total current: 40mA.

3. Wall sensor: There must be many clever ways of detecting a wall, but the simplest is a micro-switch. It is electrically simple, compact and robust. The software designers asked for two, one on each front corner of the vehicle, and wanted a single I/O bit to go low if either was triggered. Clearly an OR gate is what we are looking for.
Total current: 20mA.

4. Pneumatics: This circuit must take a logic signal from the microprocessor and amplify it, producing a large enough current to drive a solenoid (which switches the airflow). The only high current device available is a MOSFET, and with the gate connected to the microprocessor pin and the source letting current through to the drain.
Total current: 520mA.

INITIAL CALCULATIONS FOR PROTECTION RESISTOR VALUES

DeviceSupply voltageForward VoltageCurrentSeries Resistance
Indicator LED5V1V720mA 165R (180R)
Infra Red LED5V1V2535mA107R (100R)
Phototransistor5VN/AN/A33k (33k)

Power considerations: There is a 1A supply for the entire robot. The microprocessor and motors can use up to 400mA, which leaves 600mA for the circuit boards. The total for the above plans is over 700mA, which is far too high! Some improvements must be made.

PROBLEMS ENCOUNTERED

1. The Line Detector: The original idea would use up over 200mA if everything were switched on at once. This is excessive, so we will cut down a little. Tests with two line detectors showed that crosstalk is not a problem if the detectors are more than about 1cm apart, so we decided to leave the emitters on all the time. This meant that the emitter diodes could now be used in series to save current.
2. Temperature Sensor: This circuit turned out to be too insensitive, as I had not noticed just how tiny 40 µV/K is. A change of 1°K is just 1/6000th of a turn on a 20-turn potentiometer spanning 5V! Clearly the threshold temperature cannot be set accurately like this. I therefore added a gain stage: a 'zero' drift op-amp, with feedback to produce a gain of 100, now making 1°K correspond to 1/60th of a turn. This can be improved more by putting fixed resistors in series with the potentiometer, so that the potentiometer only adjusts between 2.25-2.75V instead of 0-5V. In the final circuit, a degree is 1/6th of a turn, so a 10-turn potentiometer has a convenient range of about 60 degrees.
3. Wall Sensor: We initially planned to use a de-bouncing circuit here, but it seems to be unnecessary. The microprocessor can still detect the change in level from "0" to "1," even when the transition itself is not well defined. The switch can therefore be connected straight to an OR-gate. Once the software group had done some testing they discovered that only one micro-switch was really needed, so even the OR-gate was unnecessary, but it was too late to remove it and one leg has simply been permanently connected to ground. (Actually only a NAND gate was available, so the micro-switches were connected as normally 5V. The effect is the same: the output goes high if either switch is triggered. The other switch is really permanently 5V).
4. Pneumatics: The only MOSFET we can use is in fact an N-MOSFET. I initially specified a P-MOSFED circuit, but connecting the load to 5V instead of Ground easily solved the problem.

INTEGRATION AND TESTING

Putting everything together was surprisingly painless: in other projects I have seen, parts have simply not fitted together at this stage! The circuit boards worked perfectly, although the plugs for connecting 12V power and solenoids had bad connections and kept cutting out with movement. (This was not our fault! The power lead that was prepared for us had the same problems.) The leads were cut short and soldered to the pins: an effective, though not very elegant solution.

The chassis was nicknamed "your flexible friend" for a while because it deformed enough to lift the line sensors out of range, so some stiffening angle was added.

ROBOT PERFORMANCE

The good news: During tests, the robot performed reliably with the speed well below maximum. When the speed was increased, the robot initially had many problems manoeuvring. By adjusting many of the program's constants, the reliability improved again, and the robot could deliver quickly enough to meet the time limit.

The bad news: About 30 seconds into the timed trial, the microcontroller began executing random commands and refused to run the computer's program. Indicator 0 was flashing, which I am told means a communications error. We flushed the link and also tried rebooting the computer but could not control the robot. During the next few hours we got it working for a few seconds at a time. Using a different computer and a different microcontroller made no difference. It worked once for about a minute, delivering a fitting properly, but we still could not identify the problem before we were required to hand in the robot for marking.

CONCLUSIONS AND RECOMMENDATIONS

Apart from the unidentified control problem, the robot performed fairly well.

ActionProblems
Get from starting area to collection bayOccasionally goes straight on, into wall
Lift fitting in correct part of jawJaw sometimes lands on fitting
Set off with fitting in right directionOccasionally fails to turn around at C
Arrive at D1No problems
Arrive at D2No problems
Arrive at D3Sometimes does 45 degree turn too early
Get back to starting areaOccasionally turns left early and gets lost

Where "sometimes" means about 10% of the time and "occasionally" means about 5% of the time (these are guesses, hence the vague terms, since relatively few runs were done with the program exactly the same). The error probabilities add up to make a round trip success rate of only about 75% for random temperature fittings. The temperature has been read correctly every time since the values were calibrated properly, except when the fitting was lifted badly and wasn't near the thermocouple.

To improve on the above problems, I propose more tweaking of the program as was being done before the test. However the much more pressing issue is finding out what went wrong on the day of the test. I propose a methodical investigation, first verifying that the problem is reproducible and then finding out what affects it, by changing one variable at a time. Failing that, looking up "communications error" in the manual may help.

This robot looked like an almost total success until the day of the trial. It is robust, well built and able to accurately lift and position the fittings. The problem unfortunately appeared far too late to have time to identify it. Given another few hours, it is likely that we could have sorted out the problem completely, but that is so often the case!

Finally, the project has been a very enjoyable and valuable experience for myself and for the rest of the team. I look forward to the next major team practical in the engineering course!