Robo-blog

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 | 2 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

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 »