The Gathering of Information

Today began with performing some basic measurements to verify some information that appeared in a past report, as well as some additional information.

Firstly, I verified the wheel parameters - specifically the number of marks on the optical wheels.  I didn't expect an issue here, and there wasn't one.  There are 24 repetitions of the black-white pattern (so there are 48 sectors on the wheel, and 96 quadrature states).

Timing the motor was a simple and obvious thing to do - the motor manages a revolution in 0.79s, at 13.6V.  Assuming a perfect quadrature signal, each state will last 8.23ms at this speed.  The report I've seen uses a similar assumption (but doesn't declare it), but uses the quoted 65RPM at 12V from the motor datasheet.

Obviously, it's difficult to get perfect quadrature from a wheel sensor.  To account for this, I assumed that with decent tuning, the shortest state will take no less than one sixth of the total quadrature period.  This gives 5.5ms per state at the measured speed.  To allow a bit of room, and to make the numbers nice, that means that the wheels sensors must be read at least every 5ms.

There are various options to monitor the wheel sensors:

• Polling using the microcontroller - this places a demanding time constraint on the system
• Using a timer interrupt - this makes things a little easier, depending on other loads placed on the microcontroller
• Using a hardware latch to cause an interrupt only when the wheel has moved to another state
• Using a PEEL or quadrature decoder IC - this might make the system unresponsive, as the microcontroller may receive updates less often.

Guidance System

It seemed like a good idea to consider the calculations that the guidance system will need to perform.  Dead reckoning only requires the sum and difference of the wheel position counts at any given time to update the position.  To accurately control the motor speeds, some sort of time averaging will need to be used.  This value won't be needed by the dead reckoning system, and so it shouldn't rely on it.

When the robot is moving, the position should be updated quite often, to keep arc lengths short - this allows the use of small angle approximations.  The trigonometry used in the turning algorithm needs to maintain accuracy in the direction vector, but ideally will allow incremental updates to save some CPU time.  It would be handy to be able to determine when denormalisation or accuracy loss has occurred, and have the ability to redo the calculation from scratch in this case.

The guidance system should have a system for resetting the position to zero.  It could allow orientation to be reset too, though this implies a rotation transformation, unless the position is also zeroed in this case.  One possible mechanism would be to zero both, moving the current values into a buffer to be read out at some future time, when the driving system is free to do so.

It's important in any case that all distances are accounted for - just as money should never 'disappear', in dead reckoning, movement shouldn't, or 'value slip' will occur and the position and orientation will not be valid.

Multitasking

Ideally, I want to implement a pre-emptive multitasking system on the microcontroller.  This allows some freedom in terms of performing tasks that take some time to complete, without sacrificing the CPU time required to perform more hard real-time tasks.

Objectives

At this point, I've thought up some relevant objectives for the project:

• Be able to navigate to a reasonable degree of accuracy
• Be able to follow a line of unspecified colour (light-on-dark or dark-on-light)
• Be able to execute smooth turns
• Be capable of performing speed-runs of courses (optimising the path through markers to get the best time)
• Be able to 'return to base', for example to recharge.  This implies an ability to align quite precisely with a fixed object.

Mechanics

I figured that it might be reasonable to assume that a (spinning) motor exhibits dynamic friction, so the torque at the wheels may be a linear function of the PWM input, at a given motor speed, with an offset to account for motor, gearbox, and bearing losses.

Static friction needs to be maintained at the wheels to prevent them slipping - this limits the wheel force that can be used to accelerate the robot either linearly or angularly.  This in turn limits the allowed path changes, in a predictable fashion based on 2D rigid body laws (treating the robot as 2D viewed from above).

Motor Control IC

The L298 motor controller seems very well suited to this project - it allows separate input of 'command' (forward, reverse, brake), and 'amount' (PWM level).  While this uses an extra microcontroller pin when compared with the existing board, it will make the software to control the motors much easier to write and test.

The current board would require switching of the input command to apply PWM to the motor.  It looks like the L298 will be a good replacement.

Wheel Sensors

I acquired the datasheet for the optical (reflective) wheel sensors.  The sensors aren't in the right places at the moment, given the optimum gap specified in the datasheet.  It would be useful to make a spacer of the right size to calibrate the gaps for each sensor.  However, the gap is in imperial units and provides a very awkward metric measurement that doesn't match well with any of the sheet metal in the workshop.  Hopefully something will turn up that will do.

The sensors have infrared transparent dust covers, so daylight shouldn't affect them much.  Most of the floor sensors are too far off the ground, and aren't even mounted squarely.  The datasheet lists recommended cleaning solvents - this might be handy later.

I thought about making shrouds for the wheel sensors, if daylight turns out to affect them.  If they were to be used, the inside would need to be matte black to prevent internal reflections occurring.

Motors

I managed to find a datasheet for the motors.  There's quite a lot of information in there - I'll need to take a closer look at some point.  From what I can see on the robot, there are no capacitors mounted on the terminals.

ITX Power Supply

The power supply for the ITX board is a picoPSU (the 120W variant, I think).  According to its datasheet, it shuts down if the inlet voltage goes above about 13-13.5V, and the 12V output is just switched, not regulated.  This means that a DC-DC converter will definitely be needed at the input to allow running off a battery.

A brief search on RS shows that suitable off-the-shelf units cost around £35.  That's quite a lot of the budget, so I'll look into the existing design, and consider building one.

Microcontrollers

I got some more data on PICs and AVRs.  I also had a look at the AVR instruction set, which appears to be far more extensive than the PIC instruction set.  One of the main differences between the two families is that AVRs use SRAM, while PICs use register files.  However, the AVR has 32 general purpose registers, as opposed to one working register in the PIC.  Some of the instructions take multiple clock cycles in the AVR, while all instructions in the PIC (except branches) take four.  The peripherals provided are very similar in nature, though it appears that AVRs have more of each, even in the low-end chips.