I just got back from another brilliant MINOS conference at Royal Holloway University London (http://www.micromouseonline.com is the main contact point), I presented my latest work on rapid prototyped parts for my mouse, a bit more on that a bit later!

Plenty learnt and much to do – so hopefully I will do it this year.

My input power comes from a 7.4V pack of lipo batteries, usually about 300mAh capacity, I need 5V for my motor encoders, and 3.3V for the rest of the circuit.

The current load is fairly high, it bursts up towards 1A when the sensors are going (roughly 1/10 duty something is on). So fairly high current requirements.  I also need something with a reasonable dropout , as I can run the batteries down to 6V – so a 1V dropout for the 5V line.

Putting my ‘It would be nice to get something for free’ hat on I turned to samples! I use TI for most of my sampling needs, and the REG104 series looked pretty good. Cheap linear low drop out regulators that can take some throwing around and come in fairly accessible packages.

http://focus.ti.com/docs/prod/folders/print/reg104-a.html

They don’t get too hot when running, and only require a few external parts. So meet all my requirements, so much so I always have a pile of then on standby for random project usage.

I got a pile of 20mm long, about 5mm diameter red lasers from a random seller on ebay and plugged it into a microcontroller development board with a few additions; a potentiometer to adjust intensity and a red colour sensor (TSL250R). The colour sensor is a pretty basic affair – very similar to the IR photodiodes, just sensitive to visible red light. You can get this device in 3 different sensitivities, I got all three but only tried the highest sensitivity one.

Now the main motivation to use a laser is that the beam does not expand much over distance, so instead of having some messy interplay between the cone a normal LED creates and the reflected intensity of light, there is just reflected intensity. The dot it creates does change size over distance, so its about 2mm diameter at 10mm from the lens and maybe 4mm at 100mm. But it works! I got a few volts difference on the receiver output over a 160mm range.

BUT there is a problem, not a huge one mind; Under normal circumstances when an LED sensor is looking perpendicuar at a wall the receiver is nearly always covered in the reflected light. Problem with the small focused dot is that is does not form a cone which covers the sensor. Due to the configuration shown in the photo above you can see the reflected dot on the receiver, this saturates the sensor and makes the readings nearly useless. This is overcome by mounting the receiver vertical to the laser, but a wobbly wall or ultra reflective walls could still potentially cause a lot of problems.

The other problem is the lasers’ size – they are huge and fairly heavy. I am sure there are smaller ones somewhere, I’ve just not found them anywhere. But watch this space!

So important parts to mention are that the Bluetooth module was from sparkfun.com and is not currently available (although there are many similar alternatives, and the schematic / pcb footprints are avaliable from opencircuits.com). The crystal value is set to some random value (around 4.2Mhz), it allows me to run at a really random clock speed (73Mhz after PLL), but gets me perfect for 921600 baud uart – which how fast I run the bluetooth module. I run both PIC’s at that speed so the intercon can be easily set up to the same speed – any arbitary setting value will work. By the way I the net I named as spi on the schematic nets are just ‘interconnects’ as they are on the retargetable pins.

Here is the pdf, you might want to use the rotate functions – or adopt a weird pose…

Public Release Jan 2011 – Micromouse Schematic

Questions in the comments area!

So new electronics time I think, I am going to keep the chassis and just work on my ESD and layout. I think I will keep with the two processor design as I have a couple of DSP related things I want to try with the sensors and it requires quite a lot of processor grunt to get that going. The drive electronics will stay the same, no switched mode power supplies this time, and only sensors on the front. Oh and I will keep the bluetooth – why not!

I need to design new skids as the current ones require the lower sensor pcb of the old design, so its back to Solidworks and another order to shapeways for parts. And finally – need to find some nice batteries; the ones I am using are too big and a little under capacity.

Back soon with schematic…

So, new years resolution is to get this mouse going again, I have new designs that I have been working on and have reworked the old mouse to be less of a final year undergrad masters project and more of a weekend hobby. More to come (And a site new logo has been commissioned, watch this space).

Click here to view the embedded video.

Go to http://www.youtube.com/watch?v=5a4zVuxzEdg for the HD version.

And here is the data from that run:

The todo list is as follows:

• Retune controller (there is some nasty overshoot and the control signal itself is oscillating)
• Calibrate the speeds – left and right wheel have different speeds (:() so need to go an work out the difference
• Automate this, cause it took all day to get to this point

Please note that this is a ‘jigged’ callibration – the long straight allows me to guestimate the required speed differences and ticks per meter, so not too precise at this point in time.

After implementing a fixed point maths system for the controller (10.5bits signed for those who care) and ziegler-nichols tuning the PI controller I had a one wheel mouse – putting a bit more effort in I got it to two wheels – yay.

Tuning it was a bit of a chore – so automation is king and I was able to produce this graph (yes, no axis labels, minus 2 marks for me, x is the time, y (going back into the scene) is as the gain increases and z (going up) is the velocity for said gain:

The idea is to find the point where oscillations occur, the above plot was far too noisy so a 16 point moving average was applied:

I got a value of about 1.2, but it is questionable, will compare against some simulated controllers to see if it seems a likely value – it does however work well enough to control the motors!

Now the results:

It is nice having onboard bluetooth for this sort of debugging, anyhow, things look nice – the integral term does push things out of whack when going from zero or getting down to zero – but possibly an artefact of the controller being ill tuned – there is still a large overshoot to a step input which is not what you would expect from a z-n tuned controller…

Video, go to http://www.youtube.com/watch?v=AYmkJvthVJw and click on view in HD at the bottom! or watch it in small size bellow:

Click here to view the embedded video.

Next time it will be slower and have a straight line controller built in, after that its onto cornering!

Click here to view the embedded video.

Will get a better camera in on Monday, but yay it moves. This is a very basic movement – accelerate to ~20% maximum speed, stay there and start to decelerate after 1s.

It moved very roughly, 0.5m in 1sec, making its theoretical (ish) top speed about 2.5m/s (when loaded). Although that metric does not take into account anything, so could be higher or lower :p.

Schematic for a switch for a dspic

/* Setup the IO Pin Assignment */
__builtin_write_OSCCONL(OSCCON & ~(1<<6));

	RPINR7bits.IC1R = 5;	// Switch Input Capture

__builtin_write_OSCCONL(OSCCON | (1<<6));

/* Switch Input Capture Setup */
IC1CONbits.ICM = 0x02;	// Capture on falling edge
_IC1IF = 0;
_IC1IE = 1;

/* CPU Time Clock */
T1CONbits.TCKPS = 0x02;	// 40.5504Mhz / 64
TMR1 = 0x00;
PR1 = 634*4;			// Int at 1.000631313ms*4
_T1IF = 0;
_T1IE = 1;
T1CONbits.TON = 1;

The code is fairly simple: first attach the switch input to the input capture (ic1) peripheral, set up ic1 to trigger an interrupt on the falling edge and then there is the set up for my main timer loop, this occurs at ~250Hz, and yes I am using a weird value crystal.

Next lets look at the global variables (well global to the scope of the interrupts)

// Switch input vars
int sw_counter = 0;
int sw_on = 0;

// Menu vars
int menu_counter = 0;
int menu_on = 0;
int menu_value = 0;

Next the interrupt for the input capture routine

void __attribute__((__interrupt__)) _NOPSV _IC1Interrupt(void)
{
	_IC1IF = 0; 		// Clear the interrupt
	_IC1IE = 0;			// Disable the interrupt
	_RED = 1;   		// Show the user the button pressed
	sw_on = 1; 		// Enable the debounce counter

	// If the menu is on already, increment the menu value
	// Otherwise turn the menu on and set the menu value to
	//default
	if (menu_on)
	{
		menu_val ++;
		menu_counter = 0;
	}
	else
	{
		menu_on = 1;
		menu_val = 0;
	}
}

And then the interrupt for the timer:

void __attribute__((__interrupt__)) _NOPSV _T1Interrupt(void)
{
	// Handle switch
	if (sw_on)				// If a switch 'event' is ongoing
	{
		sw_counter ++;
		if (sw_counter > 50)  	// 50x 1/250 = 200ms debounce
		{
			sw_on = 0;		// Switch no longer on
			sw_counter = 0;	// Counter to zero
			_IC1IF = 0;		// Clear the bounces
			_IC1IE = 1;		// Enable more switches
			_RED = 0;		// Led off
		}
	}

	// Menu
	if (menu_on)			// If menu is on
	{
		menu_counter ++;	// Increment counter

		// Leave menu active for 1s after last click
		if (menu_counter > 250)
		{
			menu_on = 0;	// Menu off
			menu_counter = 0; // Reset

			// Menu complete - do stuff
			switch (menu_val)
			{
				case 0:
					_RED = 0;
					Nop();	// Required if RED and GREEN
							// On same port
					_GREEN = 1;
					break;
				case 1:
					_RED = 1;
					Nop();	// Required if RED and GREEN
							// On same port
					_GREEN = 0;
					break;
				default:
					break;
			}
		}
	}
}

And thats it, google _NOPSV to find the macro for that (sometimes required to compile using c30). Also _RED and _GREEN are port bits, so something like #define _RED _RB1 to make _RED = 1 turn Port B pin 1 on. All quite useful, maybe...