Robo-blog

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 | No Comments »

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 »

Collision Avoidance- First Attempt

So I finally braved giving the robot control over its motors as well as servos, making sure that the software stop button would bring it to a complete halt should it seem intent on destroying itself or my flat… the video shows a very simple collision avoidance routine, whereby it drives until the sensor detects something too close for comfort, then evasive procedures are taken. Namely, it backs up a little to make room for a turn (the wifi dongle sticks out a long way), spins (roughly) 90 degrees, then sets off again.

Really simple stuff, but it’s already made me aware of a few issues. From a hardware point of view, the sensor is currently mounted really high on the robot, which means it’ll miss obstacles that’ll prove fatal to forward progress. Also, reversing is done completely blind at the moment! On the software side, I’m pleased to find that the motors can be issued a speed and will continue to spin until otherwise directed, meaning that you can continue to monitor sensors and run other routines without jerky move/stop/sense/think/move behaviour. The downside is that it’s harder to predict the result of time-based commands. For example, if the motors are turning forward at a rate of 30000 then a 2 second command to turn backwards will result in less distance travelled than if issued from a standing stop as it takes time to spin down.

I’ve ditched the confusing JCreator IDE suggested by CMU in favour of wordpad and compiling/running with batch files; I simply couldn’t work out the difference between projects, workspaces and files and had to clone the entire MyFirstRobot directory every time I wanted to write a new program! I’m obviously a command line guy at heart…

Posted in hardware, software, video | 2 Comments »

Second IR-tracking attempt

A long time since I last posted, thanks to BT knocking out my broadband line and struggling to recognise the existence of my new flat. So, just to confirm that the project isn’t completely dead, here’s a reprise of the previous video, showing the tracking running far faster. With my net access out, I could turn down the security on my router and so communicate with the qwerkbot over the local network rather than via an internet relay. This makes it much more responsive- so much so, in fact, that I’ve had to build time delays into the code to allow the servo long enough to reposition the sensor between readings!

As before, it’s still not perfect- you couldn’t use this to centre video, as the test for the edge of the object forces it to twitch alarmingly at this speed. Plus it loses the target entirely when it moves too far around, although (as shown) it is correctly recovered when re-presented to the sensor. But on the whole it does do a pretty good job of locking on to the toy’s right ear

Posted in software, video | 2 Comments »

First IR-tracking attempt

So I’ve been playing around with edge-detection using the sharp IR sensor and the pan-tilt unit (although for now there’s no tilting!). This video shows the simple algorithm I’ve implemented in java (running on a host PC and connecting through the CMU relay). The goal is to identify the nearest object (the initial scan) then attempt to keep it in view of the camera.

To do this, once the target is identified it pans left until the sensor reading drops off, indicating the object has been lost. When lost, backtracking mode is engaged- slowly moving right until either the object is recovered, or full-right is reached, in which case we go full-left and repeat the search. If at any point the object is found, it returns to the left-until-lost behaviour.

There’s also meant to be a killswitch option via the software interface (which features a play/stop button), but in a reassuring sign my code doesn’t always pay attention to this! In particular, it doesn’t seem to trigger in backtrack mode, as you can see from the video (where I click the button a couple of times to no effect). However, once the object is found again, it checks the play state- which is what causes it to abruptly shut down when I reintroduce the ribena berry to the environment.

Posted in software, video | No Comments »

Qwerk Quick Tip: Servos and pan/tilt assembly

Connecting a servo to the qwerk board is simplicity itself: just attach it to the pins at the front of the board, with the yellow lead nearest:

However, if you’re making the pan/tilt unit I highly recommend centering the servos correctly before putting it together, as it’s next to impossible to make this alteration once assembled! The servo horn (the plastic disc - or some other interesting shape - on the top of the servo) will have pre-drilled holes for easy mounting of components, but you want to ensure that those components point in the right direction when the servo is in its default, centred configuration.

So, plug in the pan servo to the qwerk (use port 0) and power it up- conveniently, whatever state the servos are in, the board will centre them at startup, so you don’t need to launch any software or even have a working connection. Then, line up the holes on the pan/tilt multipurpose bracket with those on the servo horn- if it’s pointing off to one side, you can unscrew the horn from the servo, then re-seat it on the still-centred servo to get a closer match. You don’t have a completely free choice of position, so you may still need to slightly compensate when mounting the servo on the qwerk itself. Similarly, you should adjust the tilt servo to ensure that the C-bracket will be mounted at right angles to the servo when centred.

Posted in hardware, pictures, quick tips | 3 Comments »

Qwerk Quick Tip: Low Power

When the battery is on its last dregs, the qwerk board won’t play completely dead: it’ll power up all the LEDs, but that’s it. Which, if you’re not expecting it, have just installed new components and then had it die mid-test is somewhat terrifying. After nervously waiting the eight hours for a charge, I confirmed that the robot was indeed fine, so the lesson to learn is that if suddenly presented with an unresponsive robot, you’re more likely to have killed the battery than the board!

Posted in quick tips | No Comments »

Build 2: The QwerkBot++

The Qwerbot+ ‘recipe’ differs from the basic model only in the addition of a pan/tilt unit; this allows the camera to look around independently of the base, and is supported in the TeleOp software interface. I also attached an IR distance sensor (upside down!) to the camera mounting bracket, giving rise to the QwerkBot++:

As usual, I’ve had to deviate from the official build. The camera I have has a slightly different mounting to the one used by the CMU team, so cannot be attached to the C-bracket in the manner they suggest. Fortunately, it does still feature a snap on/off pin, which I’ve affixed to the top of the bracket by running a screw through one of the smaller holes and into the pin. This means the camera won’t wobble around, but, having torn the base apart to get the pin, also means I’m unlikely to be able to go back to the QwerkBot design!

Rather than screw the pan servo in place, I’ve fitted sticky-backed velcro-like strips (from a picture hanging kit) to both it and the top plate. Besides saving me having to remove the plate again, this allowed me to correct for the servo: even with the horn centred as best as possible the sensors still end up looking slightly to the right, so it’s been mounted with a slight left angle to balance

I have adopted a previously-ignored part of the QwerkBot design, adding furniture pads to the battery to fit it more snugly between the screws enclosing it. I’m tempted to velcro that down too, but it’d mean charging in-situ and would be a hassle if I invest in additional batteries.

The gallery has been updated with a few close-ups of this new version.

Posted in hardware, pictures | No Comments »