Just as I've started thinking about making a board for a Raspberry Pi based robot, someone goes and makes the mother of all robotics boards - the Gertboard. Curse you Gert Van Loo! Actually it's a very nice piece of kit, but it's bigger and more expensive than the Raspberry Pi itself, and I don't think it's really what I want. It's given me a few ideas though.
The most powerful component on the Gertboard is the Atmel AVR microcontroller, which is the same chip that's at the heart of the Arduino, but it seems like overkill for my purposes. Do I really need a microcontroller on the robot when I've got a Raspberry Pi sitting next to it? It's cheap, and looks like it's got on-chip D/A converters so I could probably use it to drive the motors with variable speeds, but if I wanted that I could do it more simply and cheaply with my own circuit.
The Gertboard manual suggests that you can vary speed with pulse-width modulation (PWM), but the problem is that the Raspberry Pi only has one part-time PWM output and the switching on the GPIOs isn't fast enough for me to do botched up PWM on those. Maybe one PWM output is enough though - rather than connecting four GPIOs to the motor controller inputs, use the GPIOs to gate the PWM input - yeah, that'd work.
I'd been looking at a separate motor controller board, but wouldn't it be neater and cheaper to put a controller chip on my own board? The Gertboard has an L6203, but that's more expensive than the controller board, is specced way beyond what I need, and only has one channel whereas I'd like two. I'll have to look around and see if I can find the same IC that's on the controller board, or something similar. Would PWM work with the motor controller? Gert reckons it will with his board, and who am I to argue?
Now I'm trying to remember the circuits to do some of these things, but I've forgotten pretty much all of the analogue electronics I learnt at college. Thankfully the intaweb is helping to jog my memory a bit. If I do want variable speed, gating a PWM signal should just be AND gates so that's easy. But I'll probably want something to convert that to a stable DC analogue voltage, which is... an integrator? Can the motors take a PWM input? The GPIOs are 3.3V and the motors take 6V, so I need to step that up and be able to supply up to 2A for each motor. An OP-AMP with positive feedback isn't going to supply enough current so I'll need a hefty power transistor in there... whaddya know, I just re-invented the Low drop-out regulator... Is there an off-the-shelf LDO which lets you provide a variable reference voltage? That's basically what's in a motor controller, so I've come full circle - might as well just get one of those.
As I'm so out of practice with boards I'm a bit apprehensive about doing a complicated board in one go. It's tempting to do a smaller board first, or at least do a larger board in phases and test it between each phase. Just getting battery power to the RPi via a switching regulator would be a good start and confidence boost. At the very least I've got to start getting some schematics drawn up, not worry about exact capacitor values or board layout yet, but just start turning the morass of nebulous ideas into something a bit more coherent.
Whatever I do with the robot, it's going to need some software so that's where I'm spending my time at the moment. I'm trying my hand at cross-compiling as it's going to be faster than compiling on the RPi itself, and it's also harder than a native compile so more interesting. As I've been playing with DOSBox recently I downloaded the source for that, got the Raspbian toolchain and... wait a minute, where's the Makefile? There's a Makefile.am and a Makefile.in, what're they? Turns out they're for the GNU Autotools, which I've never used before.
Learning how to use those and how to cross-compile was a bit much to take on in one go so I took a step back and started with "Hello world". Once I'd mustered the presence of mind to write 5 lines of code which actually compiled natively, I'd got the right toolchain for compiling C++ from Ubuntu to the Raspberry Pi (g++-arm-linux-gnueabihf seems the best bet), and I'd sorted out the libraries, I got an executable which I FTP-ed over to the RPi, SSH-ed in, ran the executable, aaaand.... segmentation fault, my old friend. Next time my "Hello World" is just going to print "Segmentation Fault" so it'll look like it worked whether it did or not. It's barely worth opening up gdb, with a program that simple it's going to be a linking issue so it's probably just a matter of getting the right options in the makefile.
In other news, I've continued getting things to work on DOSBox. Speedball 2 works very nicely, it sounds absolutely awful but early PC games always did. I got UFO: Enemy Unknown working briefly but it was very slow and after I'd faffed about with the config it stopped working. It looks like I should give up on protected mode games until protected mode is improved, which it probably never will be, or DOSBox starts using SDL 2.0 with its improved use of OpenGL. And it seems that others are having much more luck with MAME than I did on my half-arsed attempt, so maybe I'll give it another go one day.
 |
| Some circuitboards, yesterday |
The Gertboard manual suggests that you can vary speed with pulse-width modulation (PWM), but the problem is that the Raspberry Pi only has one part-time PWM output and the switching on the GPIOs isn't fast enough for me to do botched up PWM on those. Maybe one PWM output is enough though - rather than connecting four GPIOs to the motor controller inputs, use the GPIOs to gate the PWM input - yeah, that'd work.
I'd been looking at a separate motor controller board, but wouldn't it be neater and cheaper to put a controller chip on my own board? The Gertboard has an L6203, but that's more expensive than the controller board, is specced way beyond what I need, and only has one channel whereas I'd like two. I'll have to look around and see if I can find the same IC that's on the controller board, or something similar. Would PWM work with the motor controller? Gert reckons it will with his board, and who am I to argue?
 |
| Wearing a bra on your head while working on geek projects turns them into Kelly LeBrock. That guy should know, he's Iron Man FFS. |
As I'm so out of practice with boards I'm a bit apprehensive about doing a complicated board in one go. It's tempting to do a smaller board first, or at least do a larger board in phases and test it between each phase. Just getting battery power to the RPi via a switching regulator would be a good start and confidence boost. At the very least I've got to start getting some schematics drawn up, not worry about exact capacitor values or board layout yet, but just start turning the morass of nebulous ideas into something a bit more coherent.
Whatever I do with the robot, it's going to need some software so that's where I'm spending my time at the moment. I'm trying my hand at cross-compiling as it's going to be faster than compiling on the RPi itself, and it's also harder than a native compile so more interesting. As I've been playing with DOSBox recently I downloaded the source for that, got the Raspbian toolchain and... wait a minute, where's the Makefile? There's a Makefile.am and a Makefile.in, what're they? Turns out they're for the GNU Autotools, which I've never used before.
Learning how to use those and how to cross-compile was a bit much to take on in one go so I took a step back and started with "Hello world". Once I'd mustered the presence of mind to write 5 lines of code which actually compiled natively, I'd got the right toolchain for compiling C++ from Ubuntu to the Raspberry Pi (g++-arm-linux-gnueabihf seems the best bet), and I'd sorted out the libraries, I got an executable which I FTP-ed over to the RPi, SSH-ed in, ran the executable, aaaand.... segmentation fault, my old friend. Next time my "Hello World" is just going to print "Segmentation Fault" so it'll look like it worked whether it did or not. It's barely worth opening up gdb, with a program that simple it's going to be a linking issue so it's probably just a matter of getting the right options in the makefile.
In other news, I've continued getting things to work on DOSBox. Speedball 2 works very nicely, it sounds absolutely awful but early PC games always did. I got UFO: Enemy Unknown working briefly but it was very slow and after I'd faffed about with the config it stopped working. It looks like I should give up on protected mode games until protected mode is improved, which it probably never will be, or DOSBox starts using SDL 2.0 with its improved use of OpenGL. And it seems that others are having much more luck with MAME than I did on my half-arsed attempt, so maybe I'll give it another go one day.
No comments:
Post a Comment