ROBOTS!!!

Finally I have my hands on a Lego MindStorms Kit. $380 later mind you. Luckily I had a win on poker which paid for it. The first thing I noticed when I open up the box was how much shit you get. I really didn’t expect to get as much stuff as you do.

I started by building the “Startup” robot which took about an hour. It was pretty simple and straight forward (as you’d hope for the beginners robot). I tested out some sample programs that are built into the NXT microprocessor. Basically the robot could play a sound, drive forward, turn 180 degrees and drive back again.

I plugged in all the different sensors that come with it too. I was really impressed with the sensitivity of them. However the only sensor that I think I will really be able to use for the stuff I want to do, is the Ultrasonic sensor. It basically returns a value of how far away the nearest object is that its facing.

My main goal was to build a robot that can move around a room (whilst avoiding objects of course) and when it finds something interesting it would be able to take readings on the object with all its sensors and report back.

So with the sensors it comes with it would -

• See how far away the object is (or maybe measure how far across it is)
• Take a reading in dB of how loud the object is
• Take a reading of what colour (or greyscale colour) the object is.

The touch sensor doesn’t seem to be of any use to me. It can be used to object avoidance but I like the idea of the robot figuring out how to not hit the wall in the first place.

With all this in mind I had the idea to make a spinning sensor rig of doom. All the sensors would be mounted on a spinning platform. This would allow the robot to drive up to the object and then just cycle through each of the sensors and take readings. Sounds like a bomb idea right? Well I didn’t think of it, NASA did. I started to modify the basic robot I had built so it would be able to do this.

It was here (without diagrams and instructions to guide me) that I realised that I completely suck at building things. When I did robotics in Uni, the robot was basically built for me and I had to program it. Even with the really easy connections that the Lego Technic provides, I had a lot of trouble creating good supports for things. I didn’t really know what most of the obscure connectors were for. I struggled through I came up with this.

The big problem I had was the rig was only supported by one pole in the middle. Because of its centre of gravity this meant it leaned slighty forward, looking down. I didn’t think it was that big of a deal. Then when I connected the wires up to the NXT block, I realised a problem I would have. The rig wouldn’t be able to spin in the same direction for more then maybe 270 degrees. Obviously because the wires would strech and twist until they stopped the motors from turning. No problem I thought. There is only 3 sensors so it can go 90 degrees either way from the start postion and back again. How wrong I was. The “gears system” I was using to spin the rig completely failed the first time any pressure was put on it from the leads on the rig.

At this point I was “programming” the robot with the software that comes with it. Basically its for kids. You use drag and drop blocks onto a line which represents the senquence of instructions the code is executing. You can’t (without doing some crazy shit) do simple switch statements or complex if statements. Loops are a nightmare because you go across the page and when there are a lot on instructions in a loop the whole program is really hard to read.

I had looked into other ways to program the NXT before I got the kit. RobotC and NXT#
were the two I found. I wanted to use NXT# as it would allow me to do more (multithreading etc). However for it to sent commands to the brick you have to have a bluetooth connection on your computer. So I went out and bought a Bluetooth dongle and installed it. It was the cheapest one I could get which was my downfall in the end. I found out after a full day of googling that the driver for this dongle isn’t supported by the NXT Bluetooth on the brick.

So I looked into the RobotC option. It allows you to write in C (a cut down version). You can access the motors and different sensor ports and then you can download the assembly to the brick via USB just by pressing F5.

So with this new way of programming I decided to redesign my “MidgeBot” to only be able to see. My new plan was to make the object avoidance a lot smarted buy making the ultrasonic sensor be able to be moved around to look in different directions. After a couple of iterations I came up with this.

After a day of programming I have it doing the following (with a few bugs left to go).

• When the program first runs it turns the head back and forth until an object is placed in front of it. This sets the head in a forward position.
• It then moves forward until it senses an object in its way.
• It then stops and scans the 180 degrees in front of it for a path that doesn’t have an obstruction.
• It then turns (almost on a dime, more design work is needed) to the heading that the “eyes” are reporting.
• Then the eyes return to the forward position.
• Then it goes on its merry way.

So at this point I have a few things I’d like to do. First, I’d like MidgeBot to reverse and turn 180 degrees if it can’t find a path. I’d also like to use the same gear system to rotate other sensors (as I’ve used up all 3 motors already).

When I go back to work this week I will return the Bluetooth dongle and try to get one that works.

I’m still on crappy dial up while TPG gets there fucking arse in gear so I’ll upload some videos of it in the next post hopefully.

Steep Re-Learning Curve

Over the last couple of nights I have been trying to resurrect my old Uni AI Assignment (Rar copy of files). The main problem I’ve had is just getting the thing to run! It’s been at least 4 years since I’ve use javac to compile a Java program and classpaths were my first hurdle. After figuring that out I could then attempt to compile which wasn’t pretty.

I had to make some changes, as the code was written for Java 1.1 and a lot has changed since then. After trawling through the latest API I found all the changes I needed.

The last thing to change for it to run (still a lot of code deprecated left) was the event handling for key strokes. This doesn’t sound like it would be too much trouble considering I was dealing with Threading issues before this.

Boy was I wrong, it took me about 5 hours last night to figure out the new structure of the java.awt.event.KeyEvent class. In the end I could not get any key events to fire when running the KeyListener on the Applet. I had to attached the KeyListener to a useless TextField and the events could then get passed on to the EventManager class which passes on the event to each object of interest.

Because there are more then one type of Agent in this system the EventManager object and EventHandler interface are a very good way of spreading out the workload of event handling between multiple objects (i.e fish and shark).

I didn’t write this code (or the majority of the game). When I first started to look at the code again it seemed very confusing. But once I start adding more agents with different abilities these classes should help me sort everything out in terms of events.

Its a good concept which involves objects registering to a central handler object all the events it would like to be told about. In the current version of the game these events are restricted to keyboard events.

But I was thinking of expanding this into a multiagent system where if an agent comes across something interesting, it could fire an event to a central control object which could inform other agents near by about it. The good thing about this is that each agent implements a EventHandler interface which has a method called handleEvent(Event e).

Therefore each agent can handle the event in different ways. The practical application of this would be a multiagent system in which there are 4 types of simliar robots exploring terrain let say….on Mars!

Each type of robot has different sensors in it. For example each robot has one function which might go something like this.

1. Camera vision
2. Chemical Analyzes
3. Rock/Soil Sample Collecting
4. Power Hub (A robot who’s main purpose is to refuel other robots)

So if a robot that analyzed some rock found something interesting it could inform (using a wireless LAN) other robots around it to have a look. After this has happened the original robot could then move on while others came over to inspect the site using there own instruments.The inspiration for this idea came from Dr. Steven Dubowsky who has been doing research for NASA in this area. By splitting up each ability for different robots you can build much smaller robots that can complete a task as a group. This is much more robust (IMO) and closely follows how nature has done this. For example how ant colonies have different types of ants for different jobs.

Most of my thinking in robotics comes from nature. AI through evolution of best practices for rewards is another area I think nature should be looked at.

So what is the next step in my “vision” for this program. The first thing is to implement a part of the program which I thought I had done but turned out not to be there. I thought I had got the remaining fish left to “mate” with each other and share attributes to create another fish. The other thing I plan to do is to make the “player” (or shark) autonomous as well. By getting it to see when a fish is on its own and to go and get it. Then I can run the program with “eating” as a positive outcome and see if the shark learns to do this on its own.