Older blog entries for davee (starting at number 14)

Here is an update on what I'm up too.

I have developed a board to control and process data from 8 ultrasonic or infrared sensors. It plugs into your serial port and continuously sends range information for all eight sensors, not unlike GPS.

I've also created a path finding server for the robot I bought back in November. You create a map of a building floor and the robot connects to the server and the server gives the robot a list of instructions to follow to get to the destination. This is all being done by a laptop running XP. The robot uses a laptop for processing, it's an ER-1 from evolution.com. All the software runs on the laptop, but the server can be a central server if you like.

The Pathfinder project is now in alpha test. The server is working and and fully functional. HTTP commands that are returned to the robot are 1 SETPOSITION?x,y, LOADMAP?mapname,rm1 or rm2, and GETPATH?waypoint and SEARCHMODE?0 or 1.

Loadmap loads a new map into the server. The map can be created and edited in the server screen.

Setposition allows the robot to change its start position SearchMode determines the search method. Currently Dijkstra and A* are implemented and the default is Dijkstra. These two algorithms are common in video games and work very well for pathfinding.

GetPath returns a 3 element list. The first element is the current position, the second is a comma delimited list of compass directions to move (assume 12 inches) and the third is the ending position.

The robot will process the list of directions in order. Only four directions are currently implemented, N, S, E, W. If the robot knows what direction it starts out at, via compass or by being placed in the right direction (N) all the robot has to do is turn in the appropriate direction and keep track of what direction it is going (current list item).

So, by designing a map of your facility and putting waypoints on the map, one could say 'getpath?xraylab' and the robot will ask the server for the path to the the xray lab and then proceed directly to it. avoiding obstacles in its way, but following the path given and presumably accurate.

With the software on it now, I can speak to the robot and tell it to go to a particular waypoint and do something interesting.

Once again, I've been neglecting this forum.

My current project is a pathfinding system for my ER-1 robot. Given a series of waypoints, the robot can find its way around the house without bumping into anything thanks to my sensortrak board by simply following the waypoints created by the pathfinder software. Pathfinder lets you create a map of a building or set of rooms and uses Dijkstra and A* pathfinding algorithms to find the best route between two points. This route is returned in the form of a list of turns and distances for the robot to execute. SONAR provides collision avoidance and provides real time map updates as new obstacles are discovered.

Pathfinder can be used by any PC language that supports COM objects. This includes C++, Visual Basic, PERL, Python, Delphi and more.

I'm also working on a line following module for the sensortrak board and consequentialy a charging nest.

Since I got my hands on the ER-1, I haven't put any time into the Kanati project. It's not dead, but will probably sit on the back burner until I get my hands on a real tiny single board PC.

OK, the sensortrak is moving on nicely and now I've added a new robot to the nest.

It's an ER-1 from evolution and I just assembled it today and am going through the learning curve with it's basic stuff.

In case you don't know, the ER-1 is an Xbeams (xbeams.com) framed robot that uses your laptop for its brains. It connects to the USB ports of your laptop and has image recognition built into it and a primitive obstacle avoidance system using a second camera.

It comes with a controller board for two stepper motors that are each about 8 cubic inches(2x2x2) in size to move it about and a 5AH battery, webcam and charger. The 5AH battery is supposed to be able to move the robot for a few hours, but the real limitation is the laptops power.

My normal power usage is about 2 hours. On the robot, it is 15-20 minutes. This is due mainly to the 1 amp drain from the cameras, which get their power off the laptop. This has prompted some to add a 7AH battery to the machine. There are some positive reports from doing this and no doubt I will be adding one too. In fact, I will probably add an inverter so the laptop will run longer too. Haven't seen any numbers for the power loss through these inverters. I'm sure it's hefty, but it's simple and the batteries can be hot swapped out when they are drained allowing the robot to run continuously. Several of us are collaborating on a power nest and I'm thinking it might be nice to develop a robotic battery changer so when the battery level gets low, it heads for the nest, gets a new battery and goes about its business.

21 Oct 2002 (updated 21 Oct 2002 at 02:02 UTC) »

Well, work on the SensorTrak (ex Serial Sonar Decoder) module has kept me away from playing for awhile. Sales are starting to take off. There are a lot of things to deal with when starting a new company. It's become a 16 hour a day job. Customers are being very helpful, which makes things a lot easier.

Thanks to all of you that have bought our new boards. Without you, it wouldn't be possible.

The SensorTrak has been updated to support not only the SRF04, and the sharp GP2d02 IR range finder and also supports switches. I'm working on an SRF08 version but that will not come out till next month at least. If any of you know a good marketing type, let me know.

We have also become a distributor for Devantech SRF04 and SRF08 ultrasonic sensors and the Sharp GP2D02 IR range finders as well.

There are some robot cars coming to the Baltimore area that will be using three of my boards in each one. A minor success to say the least! These cars will be ferrying people around the Inner Harbor. At least that's the way I heard it.

Look for the SensorTrak coprocessor module and sensors at sensortrak.com

Sales of the Serial Sonar Decoder is doing better than expected. There is a new version coming down the pipe, It uses RJ11 cables instead of the original headers. Mainly we are adopting an interface standard that is based on a four wire standard and the RJ11 is a good standard to adopt.

Yesterday we added the ability to handle the Sharp GP2D02 IR sensor to the board. The Serial Sonar Decoder now handles the SRF04 and the GP2D02. We will probably have to rename it now, since it is no longer strickly a SONAR board.

The board defaults to the SRF04, but with a serial command, you can tell it to use the GP2D02 on a specific port instead.

The IR sensor gives excellent short range (4-30 inches) in tenths of an inch.

Look for it at wehali.com

22 Aug 2002 (updated 22 Aug 2002 at 07:10 UTC) »

Well, it's been a couple of weeks since my last entry. I've been distracted by another project involving a 'real' robotic project in the works.

As to the status of K2, the firefighting robot, I'm using a 2 liter soft drink bottle as the 'target' since the pyro sensor does not report heat as much as it detects the thermal difference of an object from what it thinks is the background temperature. Works as well for cold things as it does for hot. Anyway, I don't need a fire burning for this stage of the game. K2 can find the bottle, and navigate to within 5 inches of it using the pyro sensor and the sonar system. It still needs some fine tuning, but that's ok.

Between the motors, head servo, ADC for the pyro and the sonar, I've used 12 out of the sixteen available ports. I expect to need only two or three more ports for another infrared sensor to narrow the angle towards the fire and the extinquishing system. If it gets too critical, I can offload the sonar functions to one of my sonar coprocessors and gain 4 more pins.

It is interesting to watch K2 roam around a room, locate the fire and get closer to it. If I used a fan like most people do, K2 allready gets within 10-15 degrees and stops 5 inches from the target. At that range, it should have no problem blowing out the fire. I want to do better. I want to be able to shoot a stream of water or foam at the flame and put it out with a 'real' fire fighting system.

Anyway, the next step is to modify the K2 to align itself dead on to the flame before triggering the fire suppresion system.

I've also added a routine to patrol an area and look for fires while it is on patrol. This patrol routine will evolve to patrol the trinity house and return to the start point after putting out the fire.

Yesterday, I added an Eltec 442-3 pyroelectric sensor. It is great at detecting people and dogs at a pretty good distance. Candles are a bit different. It seems the best I could get it to detect that candle was about 18 inches. This might improve within the confines of the Trinity house.

Began development of subsumption architectire for the kanati class. Currently have three levels implemented. Still need to smooth things out os that the different functions can be performed without slowing down the movement. Mostly this will involve a kind of multitasking some of the levels. Since the Javelin Stamp doens not really support this, it will be simulated on board.

in the meantime, Sparky, our dog, is having fun playing with K1 as K1 chases it around the house at crawling speed.

Today, I added code to allow the movement of the bot in precise distances and turn in specific degrees. K1 can now navigate the trinity fire fighting contest's house. At least it traverses an open area that is modeled on the house. I've ordered an eltec 433-2 pyroelectic sensor to be mounted on the head. It does not have line sensors yet and we will see if they are needed. Since the bot knows where it it, it may not need them. We will see.

I've relocated the left and right sonar units to the sides, over the tires, looking directly right and left, as opposed to the 45 degree of center that they had been. This required a minor change in the code, but now I can detect a room simply by the range data from the side sonar units.

I plan on building a Trinity house for the development. Seems I have a few sheets of plywood out back that will come in handy.

After working out a few bugs (there are always bugs to workout), K1 does a wonderful job of exploring and avoiding objects.

Tonight, I added a servo 'head' to hold a scanning platform and wrote the code to handle the scanning process while K1 explores it's world. The scanning process occures concurrently with other operations via a background timer.

I still need to add code for the targeting sensor and tell it what to do when it sees a target, but it all is coming along quite nicely.

I've decided to build a fire fighting robot out of K1, so I will be looking for a UV sensor in the next day or two to mount on the head. Haven't added the sound board yet either, will save that for later.

5 older entries...

X
Share this page