Rewiring and Maths

Last week, I discovered some problems in the power system on the prototyping board, which caused the microcontroller to reset sporadically.  Today, I worked on this issue, and did some more work on navigation.

Supply Rewire

The obvious place to start was drawing a diagram of the current power wiring.  It turned out that I'd not put in any significant capacitors on the power system.  The largest was a 1uF capacitor near the 7805 regulator input.  All of the other ICs had 100nF capacitors across their supply terminals.  Not surprisingly, this wasn't nearly enough to stop the power system from overflowing with noise.

As a starting point, I added a 100uF capacitor to the motor control board's 12V inlet, to damp the effect of inductive kick from the protective diode bridges.  This offered about a 1:5 improvement in the noise - not great, but a start.

After some experimentation, I ended up with the original design, plus a 100uF capacitor on the motor controller's 5V line as well as the AVR's supply.  The motor controller also has a 470uF capacitor on the 12V line, to absorb most of the transients caused by the motors and PWM.  This offered a good improvement at the main supply terminals, and provided excellent noise reduction at the AVR's supply pins.

Miscellaneous Hardware Jobs

Somehow, the left motor's command lines got reversed over the weekend.  I can't imagine how exactly, but I've put them right now.

To make testing a bit easier, and to prevent shorting of joined 4mm leads, I constructed a 4mm extension lead which is a few metres long.  It's got plugs at one end, and sockets at the other, so there's little chance of shorting anything.

Navigation

A problem is still present on the robot in that it stops navigating correctly after a while.  It starts moving back and forth erratically, and I've no real idea why.  Once I've got a serial link running, I'll try to log the activity and work it out.  Increasing the threshold for reaching a target point to +/- 2cm helped somewhat.  It always seems to happen when the robot's pointing away from the target, but it doesn't happen if the first target is directly behind it.  The AVR isn't resetting, because that would cause a test sequence to appear on the LED display.

The problem could be caused by the navigation algorithm in use.  A better one might use the heading to the target as a reference, and the distance.  To make this possible, I worked on an inverse trigonometry function.

The small angle approximation allows setting x = sin(x), where x is in radians, up to about 45 degrees.  At this point, the cosine function becomes quite linear, and can be transformed simply to get the rest of the slope up to around 90 degrees, and a little beyond.  Using some simple logic, it shouldn't be difficult to read any angle given the sine and cosine.

To test this idea, I wrote a script in FreeMat.  There is a discontinuity in the function, but this can be overcome by scaling a little, so the discontinuity is cancelled.  When this is done, the resulting function is extremely close to linear.  Of course, when using anything other than radians, several correction factors are required.  At some point I'll probably need to figure out the best way of dealing with them.  The graph below shows the functions.  Note that the horizontal axis shows the vector index of each sample, NOT the angle in radians.

Inverse trigonometry function R = cos(x); G = sin(x); B = x; C = approximation

To keep the logic simple, it should be easy to select the appropriate value for the first octant, then transform it to the appropriate octant based on the relative magnitude and sign of each component.

I managed to achieve a slight improvement in the robot's jittering, by changing the negative motor limit to -32767, not -32768.  I'm not sure why this helps, because originally the function used a one's complement (~) to prevent overflow of -32768 when negated.  I tried changing the motor gains, and duplicating nav points.  Changing the gains helped a little, it seemed, but duplicating points didn't, so I can probably rule out an array bounds fault.

I tweaked the wheel separation parameter to correct the robot's angular tracking.  This probably needs doing more accurately.

Examining the dirt stripes on the wheels shows that the point of contact moves laterally, so the wheel separation and offset are not consistent.  This limits the accuracy of dead reckoning, so a thin tyre might be advisable.