The National Space Centre is having a robot weekend in May this year: See robots from the TV series Robot Wars Compete in the battle arena Take part challenges to test your skills and win prizes Build and test your own robot, including the new LEGO Mindstorm Support your team…
It is true, I am losing my grip. A while ago I posted a link to a Japanese site demonstrating the grip available from a particular micromouse. A common way of doing this is to lock the wheels and place the mouse on a tilting surface. As the slope of the surface is increased, the downforce available to the tyres is progressively reduced until the mouse slips. Part of the downforce is lost due to the angle alone and is proportional to the tangent of the slope.
In general the dsPIC is well blessed with peripherals. The dsPIC30F6015 I am using at the moment has two serial ports in addition to a couple of SPI ports and an I2C port. These UARTs seem pretty easy to use as well. Still, like other peripherals on the dsPIC, they still found a way to catch me out. My own fault for not reading the data sheet properly. The trick here is to realise that there are FIFO buffers associated with the ports.
Time to do some tuning of the motion control parameters in Decimus. First I wanted to get some idea of how it is behaving with the initial settings. I have added a simple flight recorder function. A 4 kB buffer can hold up to 2000 integers. These are placed in the buffer on every timer tick. Thus I can record one second of two integers. this isn’t much but it is all I have available on the processor. Any future mouse will have to have a bigger data buffer.
After a bit of a break, I have done some more work on Decimus, my DC micromouse. With all the peripherals tested and working, I have been concentrating on the motion controller or profiler. This has turned out to be harder than I expected. The basic idea is simple enough but the implementation turns out to be a bit tricky. Probably in part because I wanted it to be useable with Primus, the beginner’s stepper-driven micromouse.
Tonight was the monthly Midlands Club meeting. The club meets on the first Monday of each month at the Technology Innovation Centre in Birmingham. We have been running for a couple of years now and anyone interested in micromouse or robotics in general is welcome to come along for a chat. We had a modest turnout tonight, a good chat about (mostly) mouse related matters and a talk about VHDL from Tony Wilcox. There were a few mice to have a look at and compare notes. It was good to see Andrew Lloyd return after travels afar.
This one was pretty stupid really. The motor drivers are H-bridges made from complementary pairs of MOSFET (the Zetex ZXMC3A16DN8 (datasheet). These need a proper driver chip to ensure good turn-on and turn-off times because of the gate capacitance. for the driver, I used the common Maxim MAX4427 (datasheet). There are several alternative equivalents. However, instead of using the motor supply (battery positive) for VDD, I used the +5V logic supply … stupid.
It was all getting too awkward. A bit of short sighted design on my part had the Nokia LCD sharing an SPI port with the motor encoders. This meant that I had to turn off the encoders to write to the LCD. While no motion information would be lost by doing this, it effectively meant that I could not, for example, have the mouse hold position while updating the display. In the end I took it all apart and patched the circuit board so that the LCD is now driven from the SPI1 port and the encoders are on the SPI2 port.
I like to check out the various Japanese micromouse builders's site to see what they are up to. Google translations sometimes make some sense but it is very hard work. I was looking on this blog the other day: R & D daily: work out. The author (whose name I…
Now that Decimus has all its bits fitted, it is time to get on with the more serious business of driving it about. The basic code for the motor PWM driver has been tested and suitable drive commands can be sent to them. Since this is a PWM system, a motor command is effectively a percentage of the battery voltage applied to the motor. The encoders produce about 26 pulses per millimeter. This has yet to be calibrated. A very simple speed control has been implemented for the first test.