Motor Feedback and Hardware Design

Today I tested whether low-pass filtering of the current sense signals from the motors was of any use, and investigated some methods of getting motor speed feedback.  I also considered the use of the AVR's pins, and looked into obstacle detection and mapping hardware.

Current Sense Filtering

The current sense signals from the motor controller are pretty noisy, and the left motor's slightly sick commutator sometimes drops out and makes the signal even worse.  I tried applying a simple first order low-pass filter, with a cutoff frequency on twice the PWM frequency.  While the noise was reduced very slightly, the most noticable change was that the PWM signal became more rounded off.  This simple test showed that it might be very difficult to achieve a decent improvement in the signal.

Motor Speed Feedback

While the motor back-EMF hasn't yet been investigated, and is thus still a viable option, it seems sensible to assume that it will also be quite noisy, and to have a backup plan for determining the motor speeds.

The following two options are the simplest alternatives:

1. Timing how long a state change takes on each motor

• A reasonable resolution on time can be achieved using a timer-counter module
• A 1/x (reciprocal) calculation is required to determine velocity
• The states will never be quite the same length, so some averaging must be used to reduce this error
• The error due to state length variation could be quite significant
• State changes would need to be recognised immediately, i.e. interrupt-on-change.
• A filter would be required to prevent multiple transitions causing multiple interrupts.  This increases hardware complexity.

2. Counting the number of states in a given period

• A moderate error due to counting is present (+/- 1 count)
• A lag is introduced due to the counting
• Using a 'sliding window' to average acts like a low-pass filter with additional delay
• More samples can be used to achieve higher resolution
• Fewer samples can be used to achieve better time-response, for example to achieve coarse control.

Controlling the motors shouldn't be too difficult - given the velocity error, a driving or braking signal can be fed using proportional PWM.  An offset of the feedback would compensate for the natural slowing of the motor due to friction.  The precise transfer function is difficult to analyse off-hand, because the controller acts neither as a constant current nor constant voltage source.

Motor reversal could be limited to only allow driving in the 'wrong direction' within a small band in the centre of the graph.  This would prevent excessive strain on the mechanical parts, and should allow better control of the robot.

A PID (Proportional + Integral + Derivative) scheme could be used to control the robot, though this may be too complex and might not be required due to the navigation feedback which will be in place to correct integrating errors.  To start with, I'll use a simple feedback scheme, and add complexity if necessary.

Hardware Considerations

Use of the AVR's pins should be carefully considered before diving in to make a PCB.  Therefore, I've considered the hardware that I might want to connect to the AVR.  I'll leave PORTB with an 8-LED display to allow status indication, and allow the SPI to be used if necessary later.  The wheel sensors and motor commands will be moved to PORTC, and the JTAG and TWI capabilities will be left unused.  Should the Two-Wire Interface be needed later, the board will be modified slightly (by way of cutting tracks at designed points), to release these pins for use.  I've checked that the software (with slight modification) works as before.

Now that the wheel sensors aren't connected to the SPI, some resistors have been removed from the circuit.

I've looked into obstacle detection hardware.  SONAR modules seem to be quite poor, expensive, and fairly hard to come by.  I did, however, find a series of infrared modules by Sharp, which use a linear CCD array to determine the distance to an object by the position of an infrared spot projected outward from the sensor.  Various detection ranges are available, and the sensors are widely used by hobbyists.  Some people have mentioned noise problems, but the best solution appears to be nothing more than adding a low-pass filter, grounding the conductive-plastic case, and averaging multiple samples.  The modules produce outputs about every 40ms, so they're medium-speed (~25Hz).  The output is analogue, and is roughly proportional to the reciprocal of the distance to the object.  Digital ones which give a close/far indication are available too.  The cheapest units I found are about £10 each, and work from 10-80cm distance.  Many hobbyists mount the sensors on servos, and use them to scan an area.

More recently, I've found some ultrasonic modules from Rapid, which may be useful.  The standard one gives a single output as a pulse delay, while the high performance version uses a I²C bus, and stores up to 16 echoes.  I've wondered whether a hybrid system utilizing both of these technologies would be useful.