Robo-blog

User Interface with Processing

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…

Posted in software, video | 1 Comment »

Basically Speaking

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!

Posted in hardware, pictures, shopping | No Comments »

Speak to me, breathe

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.

Posted in hardware, pictures, quick tips, shopping, video | No Comments »

Basic Manoeuvres

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.

Posted in software | No Comments »

Autonomous Roaming

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…

Posted in software, video | 3 Comments »

Home Shopping

How to maintain an expensive hobby during the credit crunch? Recycle!

I was back at my parents’ over the holiday period, and whilst I was there I had a rummage through the garage, in search of my old remote control car. Half-buried in a musty box, I found it, and set about looting it for parts of possible use for the robot.

I hit the jackpot on the power front: three 7.2V batteries (12,13 and 1400mAh), and a fast charger that’ll replenish one in 30 minutes, instead of the 9 hours it currently takes me! So (assuming they’re still good after all those years in the cold), I could run the qwerk board continuously: no more power failures to interrupt a coding spree!

Also found: radio gear- a transmitter and receiver capable of controlling two servos; an old manual speed controller (with some useful wires attached); a pair of servos; a switch; battery mount (too big for the qwerk, alas); and loads of nuts, bolts, screws, servo horns and so on. All for no increase to the expense-ometer!

No idea what I’ll use any of that lot for, although moving the I/R sensor to a second, lower pan/tilt unit independant of the camera is tempting, to create a steadier video feed.

Posted in hardware, shopping | No Comments »

Cliff Avoidance

Very simple code, this- at startup the sensor is tilted down in such a way that it’s taking distance readings from the point about 12cm in front of the robot, which is normally just the table surface. If the sensor reading ever drops significantly (i.e., distance to nearest object increases substantially) it’s interpreted as a cliff and the robot does an about face to avoid driving in to thin air. Terrifying to watch it in action though, as several hundred quid worth of robot slowly and seemingly obliviously trundles towards the edge, green ‘happy’ light lit…

The straight line performance isn’t particularly straight, and the 180 degree turn is a bit off; I don’t have any way to determine how far its turned, such as a compass, landmark recognition or quadrature encoders on the wheels. The plan was to mix this code in with collision avoidance, scanning alternately for obstacles and cliffs- but given how close to the edge it gets even when constantly monitoring the ground, I think I want a dedicated sensor for this job. A cheaper, digital rangefinder should do the trick, and a regular check for cliffs should be easy enough to build into other projects. It might not ever be able to climb stairs, but at least it won’t fall down them now!

Posted in software, video | 1 Comment »

Motor Death?

First disaster: running some new roaming code, the ‘bot had a crash (physical, rather than software) and now the motors don’t seem to work… It was possible but unlikely that both sets of wiring had come loose in the collision, so I went through the hassle of dismantling it all to check connections, re-tape, try different motor ports and so on. All to no avail; I can’t get either motor to spin up with the diagnostic tool, and apps such as the RUR don’t offer any clues either. Running your own code dumps a fair amount of debugging info to the console, so I’ll look through that for an error message- but for now I’ve got to wait, fingers firmly crossed, for the battery to recharge as of course that ran out during testing!

If the motor controller is dead, then I’m fairly stuck; I don’t think CharmedLabs are even making these things any more. Everything else is fine - networking, camera, servos, IR input, LED output - but an autonomous robot that can’t move is no use!

Update: With a fresh charge, it seems to live; the motor on port zero wouldn’t work at first, but after switching them around to see if the problem was the port or the motor, both started to work! So now I just have to put the poor thing back together again. No idea what went wrong, perhaps low battery prevents the motors being engaged a while before the other toys die.

Update Update: After about an hour, it’s all back together and working. Phew!

Posted in hardware | No Comments »

Build 2.1

I’ve made a few minor revisions since the last build description, so I figure it’s worth an (incremental) update. I’ve been working almost entirely on the pan/tilt unit, which is finally attached to the top plate in the suggested manner- that is, with screws! The IR sensor is also mounted the ‘correct’ way up, and the new LEDs have been relocated to the reverse of the sensor bracket. In this way they’re rather less blinding, and illuminate quite a lot of the robot. For now they’re held in place with blutack, until I’m sure this is the best location and figure out a better way to fasten them.

I installed the latest firmware update - serial cable communications- something I’ve not used in a decade - as the relay servers have changed IP address. I was pleased to find this also adds options for tuning the servo ranges to the qwerk’s web interface, as I’d been having problems with the pan servo not achieving a full 180 degrees. However, despite setting the ranges to maximum (0 through 255), it still couldn’t get the complete turn. So during the rebuild I dis- and reassembled the pan/tilt unit to switch the roles of the two servos, and it can now look perfectly to the right, although hard left is still a few degrees short. Still, should be enough to do some smarter autonomous roaming routines without needing to cram more sensors on board - there’s quite a tangle of wires already!

In the opposite direction, I restricted the range on the tilt servo to prevent damage with the teleop client, as it’s now impossible to accidentally smash the IR sensor into the battery, or the C-bracket into the servo. Fine tuning in this way will probably be useful for all QwerkBot+ builds, so it’s worth updating the firmware even if you don’t need relay server access.

Posted in hardware, pictures | No Comments »

DELight Ultra Bright LEDs

Yep, more shopping. I found the Technobots site recently whilst searching for screws to support the pan/tilt unit, as the velcro tape isn’t coping too well. Whilst there I somehow ended up in the lighting section and so some Dimension Engineering Ultra Bright LEDs made their way into the basket, despite my not being at all sure I’d be able to use them with the Qwerk!

As advertised, these LEDs do come with a servo-style connection, but there are only two power pins, with control absent; presumably the DELight controller just varies the voltage directly to adjust brightness. Hooked up the qwerk’s servo ports, the LEDs work- and they’re not joking about the ultra brightness - but are purely decorative, since you can’t even switch them off.

So, armed with my wire strippers and extremely limited grasp of electronics, I set about trying to hook them up to the Qwerk’s analogue outputs. Then realised it doesn’t have any, and that what I was looking at - the screwdown terminals on the same side as those for the motors - were digital outputs. Still, that at least lets me turn them on and off, so I separated the wires (easier to do this with the servo clip still in place), cut off the clips (no going back now) and stripped some of the insulation. Then it was just a question of which wires to connect where…

There are ground (GND) and power (5V) terminals, as well as numbered terminals 00-03 and 10-13. The Qwerk hardware guide reckons these latter are input and output pins respectively, but this is actually backwards! I shunned the 5V on the assumption that this’d drive the LEDs permanently, and connected the red wires from the LEDs to 00 and 01 (second time around), with the brown wires going to ground pins. It should be noted that this is the movie bomb disposal approach to electronics - crossing fingers and choosing a random wire - but fortunately it worked just fine, and a quick test with the universal remote proved I could switch the LEDs on or off.

What’s the use? The Qwerk does have 10 built-in LEDs, but these already indicate useful data such as connection mode and activity. So (besides the challenge of attaching new stuff) I wanted a way to indicate the status of running code of my own; often it’s hard to monitor both the robot’s behaviour and text output on the host computer. For instance, I’m planning to modify the object tracking code to use green light when it has a lock, and red when the object has been lost. For autonomous roaming, I could use the LEDs to indicate whether the robot thinks the left or right direction is safer, for an at-a-glance check as to whether it’s processing sensor input correctly. Plus, well, science fiction films have taught us that all robots need the ability to glow red when angry, and all the on-board LEDs are green, so I had to correct that

Higher resolution pictures of the assembly process and end result can be found in the gallery.

Expense-ometer: £513.75 so far.

Posted in hardware, pictures, shopping | No Comments »