A pure mathematician tries to build a robot.
In an attempt to find a saner approach to my online photo storage I’m in the process of retiring the gallery install here on Straylight, so photos from the robotics projects can now be found in this flickr set. All of the blog entries should have been updated to match, but let me know if you find dead links!
I’ve finally put together some working code for tracking with the DAGU Compound Eye board instead of the Sharp IR. With four sensors instead of one, I can track in two directions, plus there’s no need for the ‘overshoot and backtrack’ approach that prevented a steady lock on a non-moving object. There’s still a few kinks to be worked out: it’s not as fast as I’d like, but cranking up the responsiveness also makes it less stable; plus sometimes it goes into strange circular motions for no obvious reason.
As a result of one of those glitches the wires to the laser card broke, which is a shame as it was proving useful in determining exactly where the sensor/camera was aimed. Still, I’m happy to have made some progress on the software side for a change! The sensor readings and servo control are abstracted through the QwerkBot class so that future hardware revisions or tweaks don’t break all my existing code, plus I’m making use of the ability to turn the IR LEDs on and off to control distance readings for ambient lighting. The next step should be to introduce motor control to try and maintain a fixed distance to the object being tracked.
Sadly, I’m still unable to perform exact turns- careful choice of parameters for one patch of carpet fails elsewhere in the flat. So I’ll have to stick to obstacle avoidance roaming rather than precision navigation. If only the quadrature encoders were supported…
Here’s the first build with the new base and omniwheels; the bot is otherwise equipped as before, but I figured it was worth renaming and versioning in anticipation of future improvements. I’ve abandoned the expense-ometer, however
My first plan was to screw-mount the qwerk board further back, so that the pan/tilt mount on the upper deck would be available, but this lead to seriously uneven weight distribution so for now it’s held in place in the middle with velcro tape. The wifi dongle still sticks out the back, but that’s always been a problem!
My first attempt at soldering up a compound eye board simply didn’t work (no variation in output across any sensor) so I’ve ordered in some jumper wires from Cool Components- along with a Laser module: what could possibly go wrong there?
Just a quick post to prove the project isn’t dead… I’ve been very busy with my PhD research, but have slowly been making plans and purchases for a significant hardware upgrade based around the YeRobot 4WD base I detailed last time.
A comment on that entry from the manufacturers suggested I’d have more success with a 12V power supply, so I managed to solder one together using AA battery boxes (holding 10 1.2V rechargeables in series) and the connector from a dead R/C battery. That indeed gave the motors enough bite to enable turning on the spot (as opposed to just steering), but I’ve now taken a different approach- by using Omni Wheels I’m able to get the desired results with the usual 7.2V battery. Which is preferable as I can charge that in 30 minutes, whereas it takes me nine hours to top up eight AAs- and I need ten!
The Omni wheels were part of an order I made with DAGU through LMR; the universal hub they offer looked like it’d fit the motors used in the YeRobot kit, which turned out to be mostly true… I’ve had to file the axles down a bit to attach the hubs, and there isn’t enough clearance with the case to push the wheels all the way on, so on a couple of runs one has fallen off! Still, the video shows that it essentially works, with the existing QwerkBot build inelegantly balanced on top; the next task is to strip off the old motors and figure out how best to attach the board to the rover base.
I took the opportunity to remove the switch and power supply connector from the YeRobot base, which leaves some holes I can hopefully fit a sensor of some description to, ideally a bumper switch for cheap collision detection. I also ordered an IR compound eye from DAGU, with the ultimate goal of using that for object tracking on the camera pan/tilt assembly and moving the existing sharp rangefinder to another servo for obstacle avoidance. So, plenty of plans as always!
After my earlier post in search of a base unit, this alternative appeared on LMR. It’s from DFRobot but available in the UK through Yerobot, and although designed for Arduino-based projects seemed big enough to accommodate the relatively huge Terk board. There weren’t many details on what’s included, but given the very low price it seemed worth a shot anyway, so I put in an order.
The base arrived fully assembled, which was a pleasant surprise. The four motors are wired up in left and right pairs so you only need two motor controller ports (although the terk has four, so it would have been interesting to try true 4WD control); there’s also a switch and a socket I don’t recognise attached, which I assume are for hooking up a power supply. As shown on the Yerobot page, the kit also includes an add-on deck for two tiers of mounting points, and another to extend the size of the base. The motors seem to be from the solarbotics GM-series, based on the double-flat output shaft, and the wheels are Tamiya.
After testing the platform’s motors worked on ports 3 and 4, I carefully swapped them for the existing motor cables (getting left/right and forwards/backwards correct based on observed behaviour causes me far more confusion than it should!), then was able to simply balance the qwerbot on the platform and take it for a test drive.
Sadly, this turned out rather disappointing. I don’t know if it’s a lack of grip on the tyres, or due to having four rather than two motors, but attempts to turn on the spot by running one side forwards and the other backwards simply produce wheel spin or slight, stuttering turns. This makes the standard Teleop interface unusable, and my custom controller didn’t fare much better- running just a single side of motors produces far more forward motion than turning. Probably fine for outdoors applications like R/C car racing, but for the uses I’m after (roaming, tracking or mapping indoors) I guess it’s back to the drawing board.
If I can find a suitable axle/hubs then I could try stripping out two of the motors to see if that helps with the steering; if I go that route I could also switch from wheels to tracks. Or with arduino boards being so cheap it’s probably worth picking up one of those just to try them out, since I now have both a ready-made platform and some spare servos.
I’ve been playing around with various control interfaces via processing, but it occurred to me I hadn’t posted anything in a while, so here’s a work in progress… at first I tried to create a mouse based steering system that would read the position within an on-screen disc and power the motors as appropriate, but it turned out to be very twitchy. So for now I’m using a direct representation of the power to each motor in the differential drive system; this might be a bit less intuitive for the user, but it has the advantage of freeing up the mouse for other tasks. In particular, I’ve set up control of the pan/tilt unit – and hence the camera – via mouselook, which should be familiar to anyone who’s played a few first person videogames. The LEDs can also be toggled by keyboard, and a few sound effects can be triggered- making sure the file definitely played, but only once meant paying a bit more attention to the way the processing and MySimpleRobot layers interact, but proved simple enough to implement.
(Video also available in High Def)
Future additions? Some visualisation of the rangefinder reading, of course, and perhaps some stock routines like object tracking, drive until obstacle etc. Ideally (and with some more sensors) I’d like it to check the sanity of the user commands, rather than cheerfully charging into walls or off tables, which’d require careful analysis of requested motor values. The interface itself obviously also needs some work; it’s hardly user friendly at the moment, as even I couldn’t quite remember the appropriate keystrokes when putting together the video!
I’ve been programming the qwerk for autonomous operation through the SimpleRobotClient, and controlling it directly through the telepresence DiffDrive client. Each is good at what it does, but I was beginning to wish I could somehow construct a hybrid of the two. With SRC you only have control via text prompts, whereas DD is great for driving/looking around but I couldn’t use it for the various features I’ve added like the LEDs and speaker. There is the Universal Remote which’ll let you tweak any individual setting, but doesn’t lend itself to composite tasks- even driving forward is impossible! Building a client from scratch – or even just tweaking the existing ones – looked scary, though.
However, I have a little bit of experience with the processing language, which is also built upon java, and today I was able to confirm that (without too much work) it’s possible to have a processing applet interacting with the SimpleRobotClient, invoking both from a parent java program to handle communication between the two. So here’s a quick proof-of-concept for that.
So on the software side my plan for a while is to build a decent control panel – toggle switches for the digital outputs, meters for the analog inputs, some sort of virtual joystick etc. There’s some crossover between the processing and arduino communities I think, so I might be able to lift some things from there!
I’ve also been window shopping for components yet again; now that I’m armed with a soldering iron there are a couple of new options open to me such as sonar and compass units. As the lack of recent posts will suggest, though, the main problem is finding spare time…
If you’re particularly attentive, you may have noticed in the previous post that I’ve adjusted the sensor mount on the pan/tilt unit. The original plan was just to tighten up the pan servo’s attachment to the base, as it was wobbling around quite a bit, but I’d also found that the I/R unit had a tendency to get knocked off centre in collisions. Correcting that proved fiddly (you have to remove the tilt servo to get to various adjustment screws), but now it’s so solidly connected I don’t think it the bracket is ever coming off I’d tried mounting it using all four screws before, but with the bracket pointed down it blocked the tilt movement. I’d tried inverting it as mounted now, but when affixed to the top of the tilt bracket it obscured the camera… this time I realised I could attach it to the underside of the bracket, and by using a longer screw the camera is able to peek over the top. Job done!
I’ve also been thinking a bit about mounting the qwerk on a new base so that I can attach some more toys; I still have those servos I rescued at christmas waiting for another sensor- or perhaps a grabber? The Lynxmotion Tri-Track is as tempting as ever, but very pricey- especially as you can’t buy it without gearhead motors, which I’ve already obtained at considerable expense. A user over on LMR recently posted a project based on them, and they do look awesome.
In a similar price range, and also from Lynxmotion, is the A4WD1 base. Stacks of room – unlike the Tri-Track, which might be very difficult to elegantly mount the qwerk on – but I imagine those four motors would simply eat batteries. The board is meant to be able to handle 4WD though!
Via LMR, this post drew my attention to this treaded base from RobotShop. It’s meant for Arduino boards which (as always) are quite a bit smaller than the Qwerk, but it should be easier to mount it on this than the Tri-Track as it’s just a case of getting the board clear of the tracks. Price is a major plus point, as are the lynxmotion mounting points; but I don’t know if the motors might be a bit underpowered. If they are, Arduino’s are dirt cheap, so I could always revert to the standard qwerkbot build and use this for a second robot
Similarly, the final option would be an iRobot Create. Expensive, once you load on some of the accessories, and not sure if they ship to the UK; but it is a robot in its own right, as well as having an api for control over serial by the qwerk. Being able to dock and recharge would be neat, as would the quadrature if it’s precise enough, but attaching extra sensors could be an engineering challenge.
So, plenty of options to ponder. I also have more ideas on the software side than I have time for… and those are more financially realistic!
A while ago I picked up a small speaker without realising that I’d need to solder wires to it; this weekend I corrected that mistake by obtaining a soldering kit from Maplin. Whilst there I also picked up a “familiar tune” electronics kit after spotting it had a more impressive looking speaker in it, figuring I could always use it for soldering practice if the robot couldn’t use it.
Despite being a decade out of practice at soldering and lacking a clamp, I managed to get both speakers wired up. Testing confirmed that both work, but I’ve gone with the larger one for now as extended use of the smaller one produces the distinctive smell of burning electronics! Although I’m concerned that the big magnet of the speaker might find its own way to cause havoc.
The first .wav files I was able to locate on the host PC were from Left4Dead, which proved entirely too creepy. Sticking with Valve, here’s a video of the object tracking code updated to use some clips of the Portal sentry turrets. There’s a known issue with the terk qwerk board clipping the start of audio files, so I’ve thrown in a 0.3second delay; this seems a bit long, so I’ll hopefully be able to tweak it to more closely match speech to actions.
Expense-ometer: (approx, lost the receipt!) £534 so far.