They all seem to be wired right with the red black yellow and on the I/O the black wire is the outermost wire towards the edge of the board on all of them.
Then the only thing left are the A to D ports. Now for a brief explanation of A to D. Most pins on a micro are either 5vdc or ground. However an analog input can be anywhere from 0 to 5vdc. The GP2D12 sensors are analog devices. The voltage changes in relationship to the distance to the object. What could be happening is there could be a problem with one of these ports on the Atom chip. So change the sensors either right or left to use AX0, you will need to change the program as well. See if using a different I/O port helps. Also there are differences in your build compared to the tutorial. Not sure if it’s just the top panel that’s installed backwards or if there are other differences. I’m not sure if the robot would avoid or attach an object if the problem sensor were fixed.
For giggles try removing either the left or right sensor, just pull the plug from the I/O grid. If the robot acts the same with one of the sensors removed, then that’s the one with the problem. 
Ok as it sits now when its in the air and the sensors are not seeing anything the left tires move forward. When I remove the right sensor from the board the right tires move in reverse. When I remove the left sensor the right tires move forward and when I remove the rear sensor the left tires move forward. This is after switching back the dip switch to mixed.
I am also trying to figure out how to change the I/O in the program. They are currently on pins 17,18,19 but on the board those are AX 1,2,3. Also when reading the botboard II manual those AX 123 are the only analog inputs that I could see.
Can you explain to me how I know what pins are what on the board and how to change them in the program?
Thanks
On the Atom Pro, IO pins 16-19 coorespond to the AX0-3 labels on the Bot Board. There are 8 Analong inputs available on the Atom Pro. The 16-19 that you are using as well as 0-3. To use one of these other IO pins, you would simply plug the sensor into one of these other pins. To change the program you would need to change the lines that look like:
adin 17, filter(temp)
To point to the new IO pin.
To make it more readable, you might try changing the code to use a constant for the IO pin such that it is easier to change later on. Something like:
; somewhere early in the program.
RIGHT_SENSOR con 17
; Now when you wish to process the input
adin RIGHT_SENSOR, filter(temp)Good Luck
Kurt
Thanks so much I will give a go tomorrow.
Ok this is the program currently loaded. I don’t see how I can use pin0 on the AX0 because there is a jumper there and only two pins left. Also about using 0-3 the motor controller plugs are on 0-1 leaving only 2 left not enough for the 3 sensors. But on the other hand I don’t see there being an physical issue with the sensors as they all react to input and like I said I have tested them as well. I guess the next thing is to figure out how I can rearrange everything to be able to use different I/O’s. Sure would be nice to just be able to do exactly what someone else has done and have this thing work.
Little help please.
[code]'Program name: 4WD1AUTO.BAS
'Author: James Frye
'Connections
'Pin 16 Jumper to battery (VS)
'Pin 17 Left GP2D12 Sensor
'Pin 18 Right GP2D12 Sensor
'Pin 19 Rear GP2D12 Sensor
'Pin 0 Left Sabertooth channel. (Throttle)
'Pin 1 Right Sabertooth channel. (Steering)
'Pin 12 A Button.
'Pin 13 B Button.
'Pin 14 C Button.
'Pin 9 Speaker.
temp var byte
filter var word(10)
ir_right var word
ir_left var word
ir_rear var word
LSpeed var word
RSpeed var word
maxspeed con 1750
minspeed con 1250
LSpeed = 1500
RSpeed = 1500
low p0
low p1
sound 9, [100\880, 100\988, 100\1046, 100\1175]
main
gosub sensor_check
LSpeed = (LSpeed - 10) min minspeed
RSpeed = (RSpeed - 10) min minspeed
LSpeed = (LSpeed + ir_left) max maxspeed
RSpeed = (RSpeed + ir_right) max maxspeed
if (ir_rear > 15) then
LSpeed = (LSpeed - ir_rear) min minspeed
RSpeed = (RSpeed - ir_rear) min minspeed
endif
’ Send out the servo pulses
pulsout 0,(LSpeed2) ’ Left Sabertooth channel.
pulsout 1,(RSpeed2) ’ Right Sabertooth channel.
pause 20
goto main
sensor_check
for temp = 0 to 9
adin 17, filter(temp)
next
ir_right = 0
for temp = 0 to 9
ir_right = ir_right + filter(temp)
next
ir_right = ir_right / 90
for temp = 0 to 9
adin 18, filter(temp)
next
ir_left = 0
for temp = 0 to 9
ir_left = ir_left + filter(temp)
next
ir_left = ir_left / 90
for temp = 0 to 9
adin 19, filter(temp)
next
ir_rear = 0
for temp = 0 to 9
ir_rear = ir_rear + filter(temp)
next
ir_rear = ir_rear / 90
;serout s_out,i38400,"ir_right - ", dec ir_right, " ir_left - ", dec ir_left, " ir_rear - ", dec ir_rear, "LSpeed - ", dec LSpeed, " RSpeed - ", dec RSpeed, 13]
return
[/code]
The jumper on AX0 is for monitoring the battery voltage which I don’t think the current program has instructions for. So you can simply remove the jumper. I am willing to look at the little guy if you want to send it to me. There has got to be a really simple problem that would be easy for us to troubleshoot.
Just for a reality check. If you simply swap the left and right sensor cables and positions, meaning physically swap the left and right sensors and swap where the cables plug in. If it IS a problem with one of the sensors then the problem will move to the other side of the bot. If not it must be the Atom module itself.
If we have time today we will try to send you a program that will display all of the sensors data in a terminal in the IDE. This would be a very powerful tool for figuring out what is going on.
We had time today 
[code]right var word
left var word
back var word
main
adin 17, left
adin 18, right ; you should get values from about 4 with nothing in front of
adin 19, back ; a sensor, to a max of about about 530 close to the sensor
serout s_out,i38400,“Right-”, dec right, " Left-", dec left, " Back-", dec back, 13]
pause 20
goto main[/code]
I think that is the program I ran before or at least really close to it. Off the top of my head the front sensors both showed ~4-530, but the rear would never show lower then around 35. I didn’t think it to be an issue but I guess this could be what is causing my problems? Any way to adjust it to show around 4?
Thanks
Oh and thanks a lot Jim for speaking with me
To see if the rear sensor is negatively impacting you, you might want to try commenting out the code that uses the values:
if (ir_rear > 15) then
LSpeed = (LSpeed - ir_rear) min minspeed
RSpeed = (RSpeed - ir_rear) min minspeed
endif
If it starts moving OK then you know that is the problem. If you still have the problem, I would modify your program to instead of doing the pulseout commands, I would do a serout of LSpeed and RSpeed in much the same way that James did for the raw sensor information. Maybe something like:
' Send out the servo pulses
'pulsout 0,(LSpeed*2) ' Left Sabertooth channel.
'pulsout 1,(RSpeed*2) ' Right Sabertooth channel.
serout s_out,i38400,"Right-", dec RSpeed, " Left-", dec LSpeed, 13]
pause 20
goto mainIf the LSpeed and RSpeed look OK, ie both going in the same direction, then I would think the program is working OK.
On the Sabertooth controller, do you have mixing mode turned on or off. My guess is that since you are outputing a Left speed and Right Speed and not a speed and turning, that the mixing mode should be turned off. Anyway I would try the program both ways and see how it works.
Kurt
In independent mode it almost works right. Both wheels will turn forward and it will move just fine however when it encounters an object it just backs straight up, there is no turning and it will just repeat that process of moving forward and backing up.
I’ve been looking over the program and I suspect there is a problem. From what I am seeing it should be running in dif mode, not mixed mode. I’m still working on it, but it looks like it’s working on our robot for reason other than the logic in the program. Give me a little time to sort it out. It’s a very new tutorial and I should have looked it over more closely before releasing it as good. I offer my most sincere apologies… 
We have changed the motor controller to be in independent mode and it works exactly the same. We are still investigating the problem. 
There is a chance our motor controller is ignoring that switch setting.
Keep it in independent mode and try exaggerating the angle of the front sensors a bit, and point it at a wall at an angle. See if it smoothly veers away from the wall.
You’re not going to believe this. James just swapped out our motor controller, put it in mixed mode and wow circle city! Our test motor controller was ignoring the mixed mode / independent mode dip switch. So we made a big mistake telling you to run in mixed mode.
You described the bot going back and forth. That can happen if you come upon a wall at close to a 90° angle. It should start turning after a couple back and forth reps though.
Whats more unbelievable is I had it correctly diagnosed all along, now that’s shocking.
I am glad you guys took the time to replicate the issue exactly as the setup in the tutorial, I am sure that is going to save a lot of frustration down the road.
The symptoms you are describing with the 90° angle are dead on and exactly the way I tested independent mode, point it straight at the wall and see what happens. Well it just backed up and tried it again and again. Glad to find out that’s just part of the behavior.
I really appreciate Lynxmotion’s willingness to stick it out to the bitter end to get this solved, even if at times I was not.
Thanks
Aaron F.
Can’t wait to go home and truly play with my rover.
Heh, now you just need to work in the PIR sensor and make it chase the cat. 
WHOO HOOO! I changed the dip switch setting to independent mode and sure enough it works. I also gave it just a bit more angle on the front sensors but it still has an issue with 90° encounters, although just and it will figure it out eventually. It does much better outside with a wide area to work then in my apartment.
If I was to add a ping sensor to the front would that remedy that 90° problem?, Also anyway someone could point me to a how to or write a bit of code to add that extra sensor into the program?
Thanks again.
Now I just need to work on getting it to Romey status
norrislabs.com/Projects/Rome … index.html
That’s what we do. We really do want our customers robots to work as advertised. This situation was unusual to say the least. We are now updating the tutorials to put the motor controller into the proper mode. I remember there was a question about the mode when they were working on it. I’m sorry it wasn’t resolved before it hit the street. 
The code is really simple. I asked James to add comments to it, and they will be posted today as well. The motor controller does not need to be updated as often as a servo. So timing should not be an issue if you wanted to add ultrasonic code to the program. There is a lot of room on the Pro for more instructions. Probably the best addition would be some simple bumper type switch on the front to catch chair legs that the GP2D12 sensors may miss. And yes I do like the idea of chasing cats. lol