An interesting observation about the ping)) code… on P0 it works nicely. On P4 I get what appear to be resets. It appears to die in the pulseout command because the LED on the ping)) stays lit until the thing resets. I have tried with both 5 and 10us pulse duration. Even more interesting is I replaced pulseout with high p4, pauseus 10, low p4 followed by the rctime command. I’ll have to do a littl emore testing but generally it is kind of odd this thing works consistently with one port pin and not another.
u did change all the pin arguments ? 
That sounds a bit strange 
Things I would wonder. Do you have the same voltage applied to pins 0-3 as you do to pins 4-7?
Do you have the jumpers in that allow you to use P4 on the ABB as an button and an LED? I doubt that this would cause the problem, but if you do you might try removing these jumpers and see if it impacts your code.
I don’t see anything else special about P4 on the Atom Pro. P0-P3 do double as Analog inputs. So it is always possible they have some special code in the atom pro that detects this and tries to do something different that is not working properly?
Good Luck
I am still using the Basic Atom (not PRO) for W.A.L.T.E.R. but am about at the end of memory again. I think I have just enough program memory left to finish the PING code for multiple PING sensors the way I have done for the Sharp IR sensors. As soon as I get the PING code finished for the Basic Atom, I will start converting the code over to the Atom PRO. I’ll be putting PING sensors on P8 - P11, which will pretty much fill W.A.L.T.E.R.'s I/O up.
I do have W.A.L.T.E.R. fully functional using the SSC-32 for servo and motor control (Hitec HSR-1422CR continuous rotation servos) and he can even wander a straight path now. 
I just installed an IRPD will stop him from backing up if something is detected to the rear. 
Yes, there is a backup alarm beep also. I have the IRPD installed on P4 - P6 and it works fine.
I just remembered that P6 and P7 are the Atom PRO’s hardware I2C pins, so I will have to see about moving the IRPD elsewhere as soon as I get some more extender cabled. I am actually thinking about getting the stuff to make my own cables so I can make the exact length of cables I need for stuff like the IRPD and PING sensors.
Since I am no longer driving any servos directly from the Atom chip itself, I have everything jumpered for Vl to the I/O pins. The SSC-32 handles all servo control on W.A.L.T.E.R. now.
For the Atom PRO, you need a recommended setting of 10 (which is 5uS due to the half uS resolution of the PRO). The setting should be 5 (it’s actually 5uS) for the Basic Atom.
8-Dale
How but some pictures of Walter. Id like to see it regardless if it is finished oer not.
I’ll be getting some updated pictures of W.A.L.T.E.R. as well as some new video soon. I have completed software v1.6.2 and am working on v1.6.3 now. I’ll see if I can get a friend to take some good resolution pictures.
I have to calibrate the rotation so I can get turns of approximately 5 degrees per unit of time. This is so I can have W.A.L.T.E.R. do a quick about face and make a rude noise if something (like my cat) sneaks up on him from behind.
This version of W.A.L.T.E.R. is almost finished, since I can’t stuff much more code into his memory. The next version (W.A.L.T.E.R. 2.0) will use the Atom PRO, motors, encoders, and have a brand new larger body.
8-Dale
I’ve done a bit of code optimizing as far as removing unecessary code and combining some routines.
I had three rotation routines that are now one single routine. Two of the rotation routines differed only in the command sent to the SSC-32, so this was combined into the Rotate_To_Bearing routine. This has an added benefit which allows all turns to be specified in 5 degree increments relative to the direction WALTER is currently facing. These turns are by no means accurate since WALTER has no way to know which exact direction he is facing and there is no sensing for velocity or direction of travel on the motors at present. This will be corrected in WALTER 2.0 with the addition of a compass module and the change over to using motors with encoders. I also got back about 300 bytes of program memory by doing this.
If something sneaks up on WALTER from behind (like my cat, for instance), he will turn about, make a rude noise at the intruder or obstacle, and then back away from it. The IRPD at the rear is used to make sure WALTER doesn’t back into anything.
I’ve added code to read the compass bearing from a Devantec CMPS03 compass module using I2C.
I will probably remove all the code to handle the PING Ultrasonic sensor for v1.6.4. of WALTER’s software, since that currently does not work.
8-Dale
I will be resuming development of WALTER soon!
There will be many upcoming changes for WALTER. I am awaiting arrival of the board that will be WALTER’s new brain, and I have the new Sabertooth 2x5 regenerative motor controller (not the R/C version).
I am moving completely away from using microcontroller modules, and WALTER will be the first of my projects (as always) to get the new toys. The new brain board will be a small ARM board based on the LPC2148 from NXP. This ARM processor has 512Kb program memory, runs at 60 Mhz, has USB, an RTC (real time clock), 2x UARTs, 2x I2C, SPI, and other nice features.
WALTER will now become my vehicle for learning how to program the ARM processors. I am already starting to learn how to program various things as I continue to learn to program PICs, and at least some of this knowledge will be applicable to the ARM processor also. I will be using this JTAG programmer/debugger to program the ARM chip using 100% Open Source tools.
While I learn how to program the new ARM processor using the development environment I have installed, WALTER will continue to run around powered by his current Basic Atom brain, which I can still tweak a bit.
8-Dale
I have WALTER operational again! I put him back together and have the new Sabertooth 2x5 motor controller working.
I have to figure out why the sensor detection flags are not being set properly. I have to severely limit WALTER’s maximum speed with these GHM-04 motors and 5" offroad tires. WALTER wants to climb walls and do wheelies at take off now!
8-Dale
I have been working on WALTER again, tweaking his setup for the new motors. I just had to find out how fast he could go… I set his maximum and normal speed to 700 and turned him loose.
He took off like he was being chased, and ran right into a wall! He didn’t have enough time to even react to his sensor detections. I am not sure I could tweak his setup enough to give him enough time to react to sensors. He almost did a wheelie when I set him down on the carpet.
At minimum, I would have to set the detection thresholds way up to at least around 60 - 70 cm. I’m going to see if there are any tweaks I can make to his code to make him respond quicker to sensor detections. It’s a shame to have to restrict these nice motors.
For now, I’ve set his maximum and normal speed back down to 200, which is fine, and allows him enough time to respond to his sensors.
8-Dale
200 seems fair. My first robot the SPY 1 had 200RPM motors and it worked great. I think this will do you good for now, but if your hungry for speed you should slowly get faster and faster altering your code in unisen with the speed to see how far you can go with speed while maintaining a good reaction time. Just my 0.02
This is my plan. I have his sensors pretty well tweaked for a speed of 200 now. I have to look at his code and see if I can improve his reaction time. I don’t have to actually change the code in most cases now because I have a bunch of constants that control most things, including move time, turn time, backup time, turn speed, backup speed, etc.
I do have one annoying problem I have to figure out the cause for and fix. Sometimes WALTER will just stop when he is backing up. This may be caused by a faulty IRPD, which is his backup sensor and alarm for things (like my cat) sneaking up on him.
8-Dale
Here are the latest pictures of W.A.L.T.E.R. These are not good, but all I have is a cheap webcam right now.
http://www.thedynaplex.org/robotics/rovers/walter/img/new-left.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-right-side.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-front.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-back.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-motors.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-right-motor.jpg
http://www.thedynaplex.org/robotics/rovers/walter/img/new-top.jpg
8-Dale
Monster Tires, just like mine!
Looks like a monster truck 
Monster ROBOT. I have the encoders for the motors, but have not installed them yet because there is not enough room for the code in my Basic Atom (819 bytes free). I also don’t think the Basic Atom is fast enough to process the data from them and do other stuff.
The PING sensor code works! I just have to figure out a place to mount it. I may put it where the front IR Ranger is now.
8-Dale
I have been tinkering with WALTER’s code again. I have been reading a lot of stuff on the Dallas Personal Robotics Group and found some interesting stuff about subsumption and arbitration for robot behaviors. The more I read, the more I thought this would be great to add to WALTER, so I continued reading this paper about subsumption. It sounds more difficult than it really is.
I have already defined and added the necessary flags to give seven different behaviors. Now I have to define the priority for each behavior and write the arbitration procedure to do the appropriate things for each one.
I think I am going to have to wait to work more on subsumption though, because WALTER is down to just 158 bytes of probram memory free and 138 bytes of RAM.
I need to get things moving again on my PIC development for the new dualPIC controller board!
8-Dale
The subsumption stuff looks interesting.
Recently I have been reading through a book called “Robot Programming, A practical Guide to Behavior-based robotics” by Joseph L. Jones and thought it would be a lot of fun to build a robot based on this.
In his chapter on Arbitration he does discuss subsumption (4 or 5 pages) and it looked like his feelings on it were mixed. My take on it was he prefered a more fixed arbitration scheme as it is easier to predict what the robot will do…
Sounds like you need a new processor!
It is, and I am not sure I fully understand it yet. I am doing my best to implement it according to what I have read, but some things are not possible on the Atoms due to lack of a multitasking kernel. I will start testing the new subsumption engine very soon!
Up to this point, WALTER has not really been too reactive to his environment. Supposedly subsumption will help blend the various behaviors for smoother operation. I am also hoping this will allow WALTER to respond faster to his sensors.
I have not activated the PING sensor(s) or the compass because they are not installed yet. I have 9 behaviors defined so far, but am not sure if all of those will stay because at least two may actually do the same thing.
Do you have a link to this paper, or is it in a book? I am not sure what he means by a more fixed arbitration scheme.
WALTER definitely needs a new processor that is faster and has more program memory. Right now, I am seriously considering am ARM9 Linux based board (180+ MHz), am NXP LPC-2148 ARM7 board (512K Flash, 60 Mhz) or a PIC18F87J50 (128K Flash, 48 Mhz). I am leaning more towards the ARM boards right now because of the faster speeds and increased program memory.
WALTER is holding at 128 bytes of program memory free right now. I am not sure how much more code I can squeeze into this Basic Atom. I have already commented out all of the debugging code and removed two routines that are no longer needed. I have also added three new routines as well as code to trigger the behaviors I have defined so far.
8-Dale
It is a book, which I purchased up at amazon.com: amazon.com/Robot-Programming-Practical-Behavior-Based-Robotics/dp/0071427783/ref=pd_bbs_sr_1/002-0366816-2951232?ie=UTF8&s=books&qid=1194878002&sr=1-1
What I meant to say was a fixed priority arbitration scheme. There are examples in the book, like if you you have a behavior to wander, which randomly gives commands to change direction and you have another behavior to charge-home, which when the batteries start getting low, directs the robot to head home to get a charge. How do you make sure that the wander behavior does not interfere. One approach is to give each behavior a priority and have arbiter decide which commands to follow depending on the priority.
The atom pro would also be a good choice as it is faster and more memory. However I think they may have some quality problems, which I hope they can resolve. I will continue to try to use it and do what I can to help them resolve issues, while I don’t have much time to devote to developing a new platform. Hopefully in a few months, I will be able to spend some more serious time developing new stuff and at that time, I will have to decide if the Pro is working sufficiently, or I will probably jump back to my Maveric board (ATmega128) or maybe depending on what some of you develop, maybe the ARM or DSPic, or…
Ah, OK, I will have to see about getting a copy of that book. It looks worthwhile.
OK, I understand now. I have coded my Motor_Control routine such that higher priority tasks always execute first. In fact, only one task executes per cycle, and that will always be the highest priority task. I’m not sure what I have would actually be considered a subsumption engine, but it is designed based on what I have read on subsumtion so far. I am beginning testing of this today, so will see how it goes. I may even shoot some video of each test, which I expect to be amusing. I am calling this code v1.8.0 because it is a major rewrite of WALTER’s software. I may even bump this version to 2.0.0 because it is that major of a change.
I would help out also, but I no longer have an Atom PRO chip to work with. I would have to purchase another one on an ABB and have somebody else put it on the board for me. I can’t afford to be killing modules that cost $60.00 a piece and can not be repaired. I have two Renesas Starter Kits now (H8/36077 and H8SX/1664) which I am going to get back to working with since I now have jumpers to allow easy access to pins. I also have to install signal headers on the H8SX/1664 board before I can use it.
My little LPC-2148 board is quite nice, although there is next to no documentation on it. It has all the nice things on it though, including an SD card slot, buzzer, a couple pushbuttons and LEDs, and easy access to most of the MCU signals next to a small prototyping area. I just can’t get JTAG ti work using either OpenOCD or Rowely Crossworks for ARM. I can program the board using the LPC2000 FLash Utility (v2.2.3) though. This board was $75.00. The LPC-2148 has 512K Flash, 42K RAM, as well as two each I2C and SPI buses.
I think I will be using this prototype board, or something very similar, for WALTER’s new brain.
8-Dale