The latest hardware revision includes the upgrades I mentioned in the previous post: there’s a compound eye IR board (above) replacing the sharp rangefinder; a laser pointer also mounted on the pan/tilt servo; a physical switch to make sure that can’t be accidentally operated; and a voltage regulator to supply it with the required 3.3V. As a result there’s an impressive tangle of jumper wires linking all of those up! It’s possible that my original soldering job on the compound eye was sound and that I was just connecting it wrongly: the “J1″ label on the board is actually next to pin 8 rather than pin 1.
I’ve also had to glue the omniwheels onto the hubs as they have a habit of falling off otherwise 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.
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.
I’ve started developing a set of basic routines for the bot which can be called upon by any particular program, rather than hard coding them in each time. As well as making programs quicker to write (and hopefully easier to read), this helps future-proof task-specific code in case I make changes to the hardware platform.
For instance, the autonomous roaming code used in the previous post performs all turns by calls to basic routines in a separate file with obvious names like turnRight45. So if I fit, say, tracks instead of the current wheels, I can correct that one file once instead of hunting down and fixing every motor command in my other programs. This will also help when the LED wires fall out and I forget which port was assigned to which colour
The ‘correct’ java way to do this would probably be to extend the RobotClient to add such methods, but for now I’m just pulling them from a separate class. It took quite a while to work out how to even do that – I lost an hour trying to master the art of importing, before I discovered that the correct approach is ‘do nothing’. I declare the methods in a class QwerkBot saved in the same place as my other programs, and then if they make mention of some method QwerkBot.foo the compiler will add that in. Handy!
However, there’s still the question of writing the basic routines themselves, and here I’m bumping into some limitations of the Qwerk and its API. For instance, a few of the 180 turns in the roaming videos are nothing of the sort! This is because I currently have no way of detecting a heading, be it landmarks, wheel quadrature or a compass module. Even from a dead stop, knowing the motor commands sent is not enough; the driving surface, and that uncontrolled rear castor, will influence the physical outcome. Poking around in the interface for the iRobot Create suggests it can be given precise angle instructions, so perhaps such a base would be a worthwhile future upgrade for more ambitious projects.
Been a while since I posted, as I’ve been busy with my studies… but I continue to tinker with the robot when I can find the time! We did a telepresence test with the robot being navigated around the flat by an operator in the Netherlands, which was a success although quite laggy!
That reminded me of a goal I’d had for a while, of the robot wandering through the flat without an operator- or more importantly, not crashing or getting stuck along the way. I spent some of last weekend putting code together for that, and here’s one of the runs that resulted:
There’s no programmed destination, only a guiding principle of going in the direction that has the most empty space, but with a couple of boxes in place to nudge it left instead of right out of my room it’ll make a reasonable stab at travelling through the hallway to the living room. In the video you can see how an unfortunate collision with a wall throws it off task for a while, but it does eventually make it through.
The next video (making part of the return trip) shows similar problems with that corner; I don’t know if the sensor angle chosen just misses the fact there’s a wall there, or if all the mirrors in the hallway cause havoc with the IR. I have managed to get collision-free runs, but the failures demonstrate that’s more due to helpful initial positioning than a properly robust algorithm. So I’ve quite a way to go with this task!
A couple of notes on what it’s actually doing. The code is set up to perform different actions based on which of four states the bot is currently in.
State 1 (Initial State) Drive forward, and collect sensor readings for far left, near left, centre, near right and far right. If all sensor readings are higher than a panic threshold, move to state 0; if the centre sensor reading is above another threshold, move to state 3; if the centre reading is not the smallest, move to state 2. Otherwise, remain in state 1.
State 2 (direction correction) Stop the robot, then turn by 45 or 90 degrees left or right based on the smallest sensor reading obtained in last scan. Set state to 1.
State 3 (collision extraction) Stop the robot, then reverse for a couple of seconds before performing a 180 turn. Set state to 1.
State 0 (panic) Stop the robot, and wait for rescue
I’m using the LEDs to indicate some of the state transitions: states 1 and 2 get a green light, 0 and 3 a red light, as you can see in the videos. As currently implemented, any direction change requires a dead-stop; an earlier version was even more hesitant, with each scan being performed whilst stationary, leading to very slow forward progress even when the path ahead is clear. A couple of things I’d like to experiment with are adjusting course without those pauses (setting each motor speed based on the vector of scans), and increasing velocity for longer stretches of forward travel (at the moment it’s a fixed 1/10th of maximum speed). The trouble is, the faster you go, the more trouble you can get into between scans! Maybe some more sensors…
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…
