Bits and Bobs

I've been concentrating on my initial project report for a while now, so I've not generated much new material.  I have been doing the odd bit of practical work, so I'll sum up several days all together here.

9th February

I wrote motor hardware control routines to keep the low-level stuff separate from the rest of the code.  I wrote similar code to poll the wheel sensors, for a similar reason.

To test out both bits of code, I wrote an algorithm which attempts to keep the distance travelled by each wheel the same.  This effectively creates a heading control system (though it's not a very good one).  It has a steady-state error in the heading because, for the motors to drive at the same speed, a distance error needs to exist (the motors are non-identical).  Hence, the robot should maintain a straight course, but the bearing will not be 'zero'.

A motor speed control algorithm will be useful at some point, though this requires more data processing, and possibly more hardware.

Multitasking seems to be a good idea.  I found a PDF article titled "Multitasking on an AVR", which uses code from FreeRTOS.  It's basically a description of how the Tick routine works, and how the volatile environment is handled.

My supervisor also contacted me regarding a trigonometry routine used in the past, described here.

10th February

I did some maths, and managed to derive a relationship between the sideforce seen at the robot's wheels, the angular velocity of the platform, and its linear momentum.  This should come in quite handy when I model the system properly.

I worked through the maths for the trigonometry routine - it seems to be quite simple, based on the angle summation identities, but adapted to maintain accuracy in floating-point systems by adding the smaller numbers together first, and avoiding using a number which is very close to, but less than, 1.

I implemented the described routine using floats (to see if it would work at all).  It seems to be far too slow, which is what I expected.  I also wrote a simple routine to attempt to carry out the correct sequence of basic movements (forward, reverse, turn clockwise, turn anticlockwise) to trace an arbitrary path.  It's iterative, and very inefficient.

16th February

Having concentrated on my report until hand-in today, I've managed to squeeze some work in.  At some point before the 16th, I converted the dead-reckoning code to use integer maths.  I figured out that, for very small angle changes, the maths converges to the trigonometric derivatives, which ends up as a two-state system with feedback.

I found a truly horrid bug in Code::Blocks (which I haven't reported, but really should do) - every time I start it I need to remove my standard (x86-64) include and lib path from the global avr-gcc compiler settings.  It seems to forget this every time I restart the IDE, and it's really annoying.  Maybe I'm missing a setting somewhere else... this was causing int32_t to be defined as int, which meant that avr-gcc would produce an int16_t.  Annoying!  If C had originally bothered to specify variable lengths, instead of backfitting them, this problem wouldn't be present.  They may have had a reason though.

I decided to set the low fuse byte on the AVR to take out the divide-by-8 prescaler on the system clock, so I can squeeze 8MHz out of it without getting a crystal, for now.

That sums up a few days - I'll continue with dynamics, maths, more navigation, and some other niceties soon!