This will be the new thread for my rover development, since the robot has a new name. I will be getting parts today to further upgrade it with more sensors and a custom pan/tilt sensor platform.
W.A.L.T.E.R. is the robot formerly known as Octabot.
W.A.L.T.E.R. is my
W heeled
A utonomous
L earning
T errain
E xploring
R over
8-Dale
Here are the latest pictures of Walter with some new upgrades and changes.
Front:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v1_9_front.jpg
Left Side:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v1_9_left_side.jpg
Right Side:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v1_9_right_side.jpg
Pan/Tilt Turret Front:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v1_9_pan_tilt_front.jpg
Pan/Tilt Turret Right Side:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v_9_pan_tilt_right_side.jpg
New IR Ranging Sensors:
http://www.thedynaplex.org/robotics/rovers/walter/img/Walter_v1_9_new_ir_rangers.jpg
I have already got some pretty nice code to read the IR Ranging Sensors, but need to decide where I want to mount the two on the lower deck. Right now, I am thinking I want to mount them so they detect right across each wheel where the current blind spots are. I also need to get 6" and 12" servo extention cables so I can activate the IR Ranger and Ultrasonic Ranger on the Pan/Tilt Turret. You can also see the PS2 game controller cable off to the right of the Pan/Tilt Turret.
You will also notice there is some unused mounting space on the Pan/Tilt Turret. I have plans for that space… 
8-Dale
Awwww hes soooo cute!! (its a he right?). The head part reminds me of E.T.! Very nice base too. I don’t think that top level is needed though, there doesn’t seem to be anything there. Like the design of the pan/tilt too. Nice camera too 
Oh, is that a caster in the front? You know what would be cool? Remove he caster, center the wheels and get accelerometers and make walter stabilize himself! Now that would be wicked sweet You can even do it without the accelerometers. Put range finders pointing down and let it use the distance to ground as a means to transfer some weight.
I like walter 
he has a cool name. Keep it up.
Walter IS a guy’s name. He is kind of cute. The ladies seem to take a liking to him pretty quick.
I have heavily modified the base from the Octabot II kit I started out with. The wheels are not stock, and I just replaced all the deck spacers to give a bit more working room. I am going to extend the electronics deck another 3/4" because I want to add an SSC-32 below the ABB.
There isn’t anything there yet…
I am going to replace that caster with two casters, one each side of where the IRPD is. Walter is a bit top heavy with the caster set so far back, but that is the only way I could get the IRPD back far enough so it doesn’t get mangled too much. Walter still bumps into some things, but I am hoping the new IR Rangers will fix that problem and take care of his blind spots in front of the wheels.
If the wheels were more centered in the base, which is not the case, it might be fun to make Walter into a balance bot. There is a Scooter Bot II kit that would be better for that sort of thing because the wheels are already centered in the base. Hmmmm, a Scooter balance bot… 
Thanks!
I just started the design of a better Octabot kit. It will have a better mounting hole pattern, be a bit larger, and will also have SES compatible mounting holes ready to accept brackets for adding legs or whatever else a person might want to add.
8-Dale
I just finished the code to read the IR Range sensors! The routine returns the distance detected and detect status (if detected within the defined threshold distance) for each sensor.
The overall detect status for all sensors is also returned as a bitwise value. The overall status value can be 1, 2, 4, or any combination of those values.
This routine will handle up to three IR Range sensors without modification. Sensor reading is done within a for-next loop.
8-Dale
I have had some real success tonight with scanning and using the Pan/Tilt Turret. Walter can now use the turret to scan for a clear path AND he can then turn to that path and start moving there.
I just wrote and tested two routines for scanning and moving.
The first routine uses the turret to scan for a clear path. It scans in 5 degree increments and exits when it does not detect anything within its detection threshold. This is currently set by a constant but it could just as easily be a variable used as a parameter to the Scan_Turret routine.
The second routine allows Walter to turn to the last clear scanned position and start moving along that path.
It works!
8-Dale
I did actually remove the empty deck and brought Walter back down to three decks. I had to make him shorter so the cable from the IR sensor on the turret would reach down to the ABB. I wanted to play with the turret tonight, and I got quite a lot done!
I wrote two new routines for Walter tonight. The first one uses the Pan/Tilt Turret to search for a clear path when Walter detects an obstacle with either of his two front IR Rangers or the IRPD (two separate behavior sets). If he finds a clear path, the second new routine comes into play - it allows him to actually turn to the course where he scanned the clear path.
If Walter can’t find a clear path by scanning with his turret, he falls back to the lower level IR Ranger or IRPD behaviors. He will prefer to use the turret to scan first, and then fall back if necessary.
I must say I am pretty happy with my progress getting the new sensors incorporated into Walter’s navigation and motion routines. I did not think I would have this sort of success so quickly.
Now I just have to get a cable for the PING Ranger on the turret and write code for it. Of course, I also have to tweak all the new code to get it just the way I want it. I will be mounting the two front IR Rangers where they will detect right across each wheel. This will cover Walter’s blind spots and is working quite well for that now.
8-Dale
I have the Scan_Turret and Turn_To_Bearing routines worjking correctly now. Walter can now scan for a cler path and turn pretty close to that bearing and continue on until he detects some other obstacle. He can now successfully avoid more obstacles than when he did not have the Pan/Tilt Turret and IR Ranging sensors.
Currently, I have two of the IR Ranges mounted so they detect right across Walter’s wheels to cover those blind spots. I just have to mount them at the same level as the IRPD.
This has been a very worthwhile upgrade for Walter! I am looking forward to getting an SSC-32 servo controller, a compass module, the Nubotics Wheel Watchers, and the Nubotics Wheel Command for Walter. With these additions, Walter will be able to know his exact compass heading, and turn to an exact scanned clear path, the direction of an interesting object/person, or a relative angle from his current heading.
With the Wheel Watchers and Wheel Command, Walter will also know how far he has travelled, and be able to navigate exact paths by direction and distance (including programmed and/or learned paths).
It may be time soon to give Walter a memory…
8-Dale
Hello,
Recently I started working on my custom built 2wd rover and I am right now trying to get the Wheel Commander to work with the botboard2/atomPRO28 combination.
The problem that I am running into is that I can send commands via the serout command to the Wheel Commander and it does receive (such as ‘K’ for the wheel commander to calibrate itself) and that works, however my problem is where I use the serin command, I do not get any responce back from the Wheel Commander, i’ve check all my wiring, even set the baud rate on the WC to 2400, so I can only send commands not receive them(kinda makes it useless like this). Everything I have is brand new. I also modified the example code from nubotics website for the basic stamp 2, still the same problem. I have nothing else hooked up to the botboard. I have even tried different pins on the Pro28.
The only thing I can think of is to make a Serial TTL converter for the WC and try the nubotics software to see if that works.
Serial communication is a real pain in the butt.
Do you have acess to an oscilloscope?
If so, that’d be a quick way to check whether the WC is actually sending anything.
You’d also be able to generally measure the baud rate if you can get it to spit out a set of bits that you know in advance.
If you don’t have access to a scope, then I’d say, break out the ol’ 232 and stick it into a PC.
Right now I am wishing I had a scope, but I Am putting together my rs232 board now.
I don’t have any experience with the Wheel Commander yet, sorry. I am going to add the Wheel Watchers and Wheel Commander to Walter, but probably not before he gets a new and larger body.
Can your PC communicate with the robot when it is being programmed? Is this the same port you use to talk to the Wheel Commander on or is the robot not getting any response from it?
8-Dale
Hi,
The Wheel Commander uses RS232 TTL Signal Levels(not level shifted) So I am using two pins on the botboard, one for TX, and the other for RX
Basically right now it appears that the robot is not getting any responces from it
Do you know for sure that your Wheel Commander is operating correctly and isn’t defective?
8-Dale
Well I know that I can send data to it, and it works, for example I can set the baud rate on the Wheel Commander to 9600, then I can send the 'k" command which is a built in calibration routine, which then does it’s calibrations(neat to watch). So I know it’s getting data at least
OK. However, it may still have a defect for sending data back to the host. I have seen serial parts be defective in only one direction but work perfectly in the other - which is not real useful most of the time unless you are just monitoring a send only device.
Have you checked your cabling from the robot to the Wheel Commnder. Many common communication problems are caused by bad or faulty cables. The first thing to do when there is a problem is check any cables that are used in the communication process.
8-Dale
Thanks,
Actually I replaced the wires just to be on the safe side, even made them as short as possible to see if that would help, but didn’t make a difference, I think it might be a bad controller(WC), which would really suck, but for what I want to do with my bot, getting data from the WC is needed.
I am building a TTL converter and it’s almost done, so maybe I will see what’s going on with it this way, using Nubotics calibration software.
Don’t toss the Wheel Commander out yet… If you are communicating with it via i2c, there is a specific recommended cable setup to use. Acronamehas standardized on using i2c for intersystem/part communication, and they have a lot of good information about it.
The Open Servo folks have had a lot of problems with noise messing with their i2c communications, and they were not using a recommened cabling setup. They are switching to a proper cable setup now though.
8-Dale
Well after talking to a few people I got the TTL converter done, used the Nubotics software, which worked without any problems.
I didn’t even try to use the I2C with the Atom Pro as of yet, from what I have been reading it’s not that good(someone please prove me wrong)
The fix is a simple one, and I hope that at some point maybe there could be a sticky for this somewhere:
You HAVE to make sure that the slow comms is set on the WC, this inserts a 40ms intercharacter delay.
I am running at 38,400 baud currently without any errors, but I am slowing it down to 9600 baud just to play it safe.
I can understand where the basic stamp would need a delay like that, however I didn’t think that the AtomPro would also need it as well.
Anyways thank you for the help everyone.
Time to get programming
I suppose that delay might be due to the makeup of the chip itself.
It’s got to interpret Basic instructions, which probably accounts for the necessary lag.
But, then again, I’m not an ATOM guru.
