One difficulty with micromouse is finding tyres, usually they are not quite what you wanted in terms of size or composition. A lot of people use tyres from the mini and micro RC car racing world, but these tyres tend to be fairly wide in proportion to their diameter. The smallest ones from the micro racing world have a 3.5 mm width with a 10 mm diameter , perfect if I were designing a new micromouse but not for my current setup which are 5 mm wide with 18 mm diameter hub, designed to carry mini-z size tyres.
Accurately cutting these is a task harder than it first looks, so in order to maximise the complication in carrying out this task, I built this:
Looking a bit closer…
What we have is a drill mounted in a drill clamp with a M13 bolt in the chuck. Somewhere on the internet I sourced a short 20 mm long steel tube with 13 mm inside diameter, so the tube goes on the bolt and we have a sort of lathe arrangement. Using a new scalpel blade cutting the tyres is easy, just need to get a bit more accurate before I dig in to the ‘final’ tyres.
As its less than a month to the UK micromouse conference I thought I had better start a push to get something working (one year I might make it!). Anyhow – a few weeks ago I got the latest version of the 3D parts from Shapeways and was a little disappointed with the outcome.
So here are a couple of images of a wheel from just over a year ago:
And the recent ones:
The left hand images show the locating boss which aligns the spur gear which attaches to the wheel. The boss diameter has decreased a little bit, but as shown in the next image one of the three came out fine (The scratches are me cleaning it up with a scalpel).
The right hand images show the bigger issue – the holes are not as round! Potentially a problem, but will have to wait a bit to see how they work out.
There are some serious issues is with the main body too, everything seems rounded off – a lot of the crisp edges have gone.
Now I have changed quite a lot of the detail on this part; I flexed the prototypes to breaking and added material as required. However the whole model is squashed, where the motors used to fit snugly in place they now have gaps around them where the loops form ovals, also the previously flat base is now un-even.
I am going to point shapeways to this post and see what happens, but at the moment the accuracy should be good enough – although in future I may need a different supplier.
I am currently saving cash for the next part of my micromouse build, so that is on the back burner for a little bit.
Doing some other work at the moment and just came across something interesting with the optimisation of the XC8 compiler for 8 bit PIC’s (some C code):
PFLAGS1bits.SW0 = PORTA & 0b10000000; PFLAGS1bits.SW1 = PORTA & 0b01000000; PFLAGS1bits.SW2 = PORTCbits.RC0; PFLAGS1bits.SW3 = PORTCbits.RC1;
I started off with the simple bit mask, then thought if the bit structure assignment would be as efficient as the bit masking. Turns out quite the opposite is true:
board.c: 129: PFLAGS1bits.SW1 = PORTA & 0b01000000; 1565 003E 080C movf (12),w ;volatile 1566 003F 3940 andlw 040h 1567 0040 00F0 movwf (??_isr+0)+0 1568 0041 0DF0 rlf (??_isr+0)+0,f 1569 0042 0879 movf (_PFLAGS1bits),w ;volatile 1570 0043 0670 xorwf (??_isr+0)+0,w 1571 0044 39FD andlw not (((1<<1)-1)<
board.c: 130: PFLAGS1bits.SW2 = PORTCbits.RC0; 1578 0047 180E btfsc (14),0 ;volatile 1579 0048 284A goto u24_21 1580 0049 284C goto u24_20 1581 1582 004A u24_21: 1583 004A 1579 bsf (_PFLAGS1bits),2 ;volatile 1584 004B 284D goto u25_24 1585 004C u24_20: 1586 004C 1179 bcf (_PFLAGS1bits),2 ;volatile
So using the structures actually creates nearly better code. I do not quite understand why the second one has so many goto’s, it should just be:
board.c: 130: PFLAGS1bits.SW2 = PORTCbits.RC0; 1586 004C 1179 bcf (_PFLAGS1bits),2 ;volatile 1578 0047 180E btfsc (14),0 ;volatile 1583 004A 1579 bsf (_PFLAGS1bits),2 ;volatile
I will assume that’s an artefact of using the free version…
Using the structures to access bits is more efficient but it would be interesting to see what the full optimisation does though.
Based on the single cell lipo from Sparkfun (https://www.sparkfun.com/products/10217) – this is my 6 ‘single’ cell charger.
It uses a Microchip MCP73831 linear charger which can deliver ~500 mA with all the special features required to charge lipo batteries. On the 120 mAh cells this equates to just over 4C charge current – a bit high, but within the cell specs.
I have a 5V 4A switch mode brick to supply power to it – everything should be within spec, although it might get a bit warm with 6 flat cells plugged in!
I finally finished designing my micromouse – slightly behind schedule, but better late than never.
To keep the routing ‘simple’ its a four layer design, internally there is a 3v3 layer and a signal layer. The 3v3 makes routing power simple, and the signal allows for troublesome signals to be routed without too many problems (the longer tracks for motor control logic, some spi and the tracks I forgot on the first pass).
I was going to use PCB Pool again, however the cost was a little to high for this board. I am not 100% sure on some of the footprints (technically they are sound, but they might not make for nice hand soldering), so >100 euro for potential coasters was a bit of a reach. This time out I am using oshpark.com, cost comes to $52.20 delivered for 3 boards, so hopefully it will work first time!
Oh and osh have some very nice graphics to verify your board layout:
Boards went for fab on Friday, so a couple of weeks before they make their way to me. In the meantime I have designed a battery charger around a microchip lipo charger chip – should give me between 3 and 5C charge times (max 20 minutes from flat), and handle 6 batteries at a time.
Well, I must admit I am impressed with the motor control capability of the STM32 series; within a couple of hours of coding I have got complementary PWM working, and the quadrature encoders hooked up to one of the timers. The one gripe I have so far is the difficulty in getting documentation to do a specific task, for motor control this is king:
Code examples of the PWM with complementary outputs can be found in the .ProjectSTM32F4xx_StdPeriph_Examples folder of the STM32F4xx_DSP_StdPeriph_Lib_V1.0.1 library.
The encoder is not covered, but its pretty simple.
Put this at the top
Then set up the GPIO so that the two encoder inputs are enabled and set as alternate function mode, and connect them to the timer (using timer 4 in this example):
/* GPIOA Peripheral clock enable */ RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE); /* AF Mode for peripherals - PORTB */ GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; GPIO_Init(GPIOB, &GPIO_InitStructure); /* Connect TIM pins to AF */ GPIO_PinAFConfig(GPIOB, GPIO_PinSource6, GPIO_AF_TIM4); GPIO_PinAFConfig(GPIOB, GPIO_PinSource7, GPIO_AF_TIM4);
Now set up the timer – using the API
/* TIM4 clock enable */ RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); /* Configure the timer */ TIM_EncoderInterfaceConfig(TIM4, TIM_EncoderMode_TI12, TIM_ICPolarity_Rising, TIM_ICPolarity_Rising); /* TIM4 counter enable */ TIM_Cmd(TIM4, ENABLE);
Now its all running, the timer 4 counter will increase / decrease with the direction bit set too.
Well post MINOS work tends to tail off a bit (unless you’re entering the competition in July that is…).
My mouse is getting there, about 70% of the PCB is routed and most of the hardware is designed bar a few alterations which depend on the final PCB. I am making the move to STM32F40x controllers, so am taking a few weeks out of PCB routing to get a handle on how they work – and to make sure I connect everything up the right way (PCB’s are going to cost about 120EUR, so want to get it right first time).
Thats a STM32F4 Discovery (~£10, programmer/debugger built in) connected to a Faulhaber motor (6V I think, with quadrature encoder and gear head). Its interfaced using a Vishay motor driver chip (floating, dead bug style). It’s a simple setup as I am not driving a load, otherwise flyback protection would be required. The STM32 dev board is supplying the 5V for the motor encoders, the motor driver is powered off the bench supply. Early days yet, its different to PIC…
As a side, I found a ‘new’ motor driver chip. My mouse uses a single cell lipo, and the Vishay can’t operate over the entire battery voltage range. One option is to make my own (MOSFET / Drivers), or get a single chip solution: BD6211F. 1A, 3V to 5.5V (logic high from 2V to supply voltage), should do perfect for my 3V, 0.75W Maxon motors.
Right then, I am going to try and do this properly this time.
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.
Wow – its only been a couple of days since I posted the schematic and already a question. Basically its asking what voltage regulators am I using.
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.
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.