H3R with Atom Pro?

[kurte]

I am thinking of at least temporarily replacing the Basic Atom with an Atom Pro (which will arrive tomorrow) on my new Hex 3R. I was wondering what all I need to do to make this work.

So far I have ah3R121.bas file that was modified with the proper offsets for my hex and updated it such that it would compile under the Atom Pro IDE. So far the only changes that were necessary were to handle the arc cosine table. The first changes was around line 101 to change the data command into a ByteTable like:

    cosTbl ByteTable  64,64,63,63,63,62,62,62,61,61,61,60,60,60,59,59,|
            ...

Then later in the ACos function I changed the two lines that looked like:

    read TmpCos,TmpAngle

into a line that looked like:

  TmpAngle = cosTbl(TmpCos)

The program now compiles, but I will have to wait until sometime tomorrow to see if it runs properly.

Are there any other differences that are needed to make the pro work? Things like timings?

Also I read in a different thread that I might need to add some pull up resistors on the Mini-ABB board to make the ps2 controller reliably work. Should I?

Thanks

[laureatus]

Hello,
you’ll need to replace all the ‘Nap’ command with the corresponding ‘Pause’ command and value.
Nap 0 => Pause 18
Nap 1 => Pause 36
Nap 2 => Pause 72
Nap 3 => Pause 144
Nap 4 => Pause 288
Nap 5 => Pause 576
Nap 6 => Pause 1152
Nap 7 => Pause 2304

i will build a BA pro version soon too…

watch your steps, this program have never been tested on BA Pro !

Ho, you’ll need to change the PS2 controller Pins too, and there’s a resistor to solder.

[kurte]

Thanks for the heads up on the Nap Command. I have also read in some other message from Jim that the PulseIn command time parameter has changed as well. Do you know of any summary document that describes all of the differences between the Atom and the Pro?

@Laureatus

i will build a BA pro version soon too…

watch your steps, this program have never been tested on BA Pro !

Ho, you’ll need to change the PS2 controller Pins too, and there’s a resistor to solder.

You mentioned needing to change the PS2 controller Pins as well. I believe that Jim mentioned this in some other thread. Something like some of the output pins are 3.3v and not 5v. Do you know which ones? I do not see anything in the Pro documents? Is it in the 28 pin datasheet?

Thanks again

[robotdude]

@kurte

Thanks for the heads up on the Nap Command. I have also read in some other message from Jim that the PulseIn command time parameter has changed as well. Do you know of any summary document that describes all of the differences between the Atom and the Pro?

The Pro just has twice the resolution. So a 1mS pulse is 2000uS where the Atom is 1000uS.

@kurte

You mentioned needing to change the PS2 controller Pins as well. I believe that Jim mentioned this in some other thread. Something like some of the output pins are 3.3v and not 5v. Do you know which ones? I do not see anything in the Pro documents? Is it in the 28 pin datasheet?

I’m not sure if it’s specific to the Pro 28 or not. You have to move PS2 controller cable from 4,5,6,7 to 12,13,14,15 and add a pullup to the data line. Here is the rather long thread where this is discussed, explained, explained again, and kicked repetitively like a dead horse… um oops sorry…

lynxmotion.net/viewtopic.php?t=1048

Let me know if you have trouble.

[kurte]

@Robot Dude

@kurte

Do you know of any summary document that describes all of the differences between the Atom and the Pro?

The Pro just has twice the resolution. So a 1mS pulse is 2000uS where the Atom is 1000uS.

Thanks Jim,

I guess what I was really asking is: Is there one place, either a document from Basic Micro or a message (preferably sticky) that says when you are converting a program that was writtent to run on the Atom to an Atom Pro, you need to change the following things:

1. There is no data statement, covert this to use the ByteTable command instead… (This one will be found by compiler)

2. The period parameter to Nap statement has changed its meaning. This one is not caught by compiler.

3. The PulseIn command time parameter has changed. Again not caugt by compiler.

4. …

@Robot Dude

@kurte

You mentioned needing to change the PS2 controller Pins as well. I believe that Jim mentioned this in some other thread. Something like some of the output pins are 3.3v and not 5v. Do you know which ones? I do not see anything in the Pro documents? Is it in the 28 pin datasheet?

I’m not sure if it’s specific to the Pro 28 or not. You have to move PS2 controller cable from 4,5,6,7 to 12,13,14,15 and add a pullup to the data line. Here is the rather long thread where this is discussed, explained, explained again, and kicked repetitively like a dead horse… um oops sorry…

lynxmotion.net/viewtopic.php?t=1048

Let me know if you have trouble.

No Problem, I will let you know how it works out. The board should be here tomorrow sometime . I was simply wondering which outputs did not appear to work properly, as I will be adding additional sensors and it would be nice to know which I/O pins to avoid. My guess is that it may be P6 and P7 as these are also used as SCL/SDA I2C pins and may be used for an external EEPROM, but that is just a guess!

Anyway thanks again

[kurte]

I am still having some fun getting sequencing of the six legs to work properly on my Hex using the Atom Pro. Yesterday I started off with the latest basic files AHR134N.

Has anyone else tried running this new version on their atom and latest IDE?

I did the conversion to make it compatible with the PRO. Changed the IO pins, Changed the Nap commands, Byte table, etc. I then compiled it with the 8.0.0 ide. I believe the COS bug has been fixed? Also the SQR?

When I first tried running this, I found that it was hanging up playing a sound. This is when I first noticed that all of the sounds were for a very long duration, like:
Sound 9,[100000(2000 + LockLegs * 1000)]
Which if I am reading this correctly should play the sound for 100 seconds. Although maybe since this is larger than 65535 may get truncated to the lower 16 bits?

I was also wondering about the statement in h3init:
Distance(Index) = TmpDistance / 127
As Distance is not declared as an array.

My current modifications are dumping a lot of debug information about the calculated servo moves. I hope to compare this with the outputs from my standard atom, when I get home.

Some of the information I am dumping includes, the XPos, YPos and ZPos arrays. For example the last output just after startup is:
96:-124:1 95:-99:0 96:-124:1 95:-99:0 96:-124:1 95:-99:0

I then output the calculate HipH_Pulse, HipV_Pulse and Knee_Pulse. This is not the exact output to the sevos as I am outputing the calculated values not the 3000-x values that happen on the legs on the left hand side. The cooresponding values for the values above were:

*1513:2040:1520 1500:1763:1741 1513:2040:1520 1500:1763:1741 1513:2040:1520 1500:1763:1741

I will let you know how these compare to the values generated on the atom.

[robotdude]

@kurte

I am still having some fun getting sequencing of the six legs to work properly on my Hex using the Atom Pro. Yesterday I started off with the latest basic files AHR134N.

I just updated the files today with 1.35. There was a bug that only effected the right joystick if it was in the 45°, 135°, 225° or 315° positions. Some controllers had more range than others and could overflow the IK. It’s limited now. The new IDE’s use uS resolution for commands that the old IDE only used mS resolution. So the notes were playing a real long time on the old IDE for this reason. That’s all I can help with. Sorry…

[laureatus]

You are right about the Distance(Index), it’s an error, it overwritte next variable in ram, anyway these variables are initialized later, so it doesn’t cause any bugs,
just remove the “(Index)” text so : “Distance = TmpDistance / 127”

about the sound command, you are using a version for BA IDE 5.3.0.0, this IDE is different than the 2.2.1.1, one of the differences is the sound syntax, it uses usec for duration instead of msec so, you’ll need to convert :
Sound 9,[100000(2000 + LockLegs * 1000)] into Sound 9,[100(2000 + LockLegs * 1000)]

and so on for all sound command from this 5.3.0.0 IDE version

there’s a new V1.35 now with a bug correction when moving the AH3-R at 45°, 135°, 225° and 315° (joystick’s corners)…
there’s just two changes here,
previously :

[code] ZCoord = DualShock(3) - 128 ; Right Stick Horizontal
if (ZCoord < DeadZone) and (ZCoord > -DeadZone) then
ZCoord = 0
endif

WCoord = DualShock(4) - 128		; Right Stick Vertical
if (WCoord < DeadZone) and (WCoord > -DeadZone) then
	WCoord = 0 
endif[/code]

is now :

[code] ZCoord = DualShock(3) - 128 ; Right Stick Horizontal
if ZCoord > DeadZone then
ZCoord = ZCoord - DeadZone
elseif ZCoord < -DeadZone
ZCoord = ZCoord + DeadZone
else
ZCoord = 0
endif

WCoord = DualShock(4) - 128		; Right Stick Vertical
if WCoord > DeadZone then
	WCoord = WCoord - DeadZone
elseif WCoord < -DeadZone
	WCoord = WCoord + DeadZone
else
	WCoord = 0 
endif[/code]

it avoids an overflow in IK

all the

serout p15,I8N1_38400, (5.3.0.0 IDE syntax)
must be changed to

serout p15,i38400,....... (all other IDE syntax)

[kurte]

@Laureatus

about the sound command, you are using a version for BA IDE 5.3.0.0, this IDE is different than the 2.2.1.1, one of the differences is the sound syntax, it uses usec for duration instead of msec so, you’ll need to convert :
Sound 9,[100000(2000 + LockLegs * 1000)] into Sound 9,[100(2000 + LockLegs * 1000)]

and so on for all sound command from this 5.3.0.0 IDE version

Thanks for the heads up on the difference in the sound command between the latest versions of the Atom and the pro.

So to make it such that I may be able to compile it on both platforms I will probably do something like:

;SNDSCL con 1000 ; use when compiling on ATOM SNDSCL con 1 ; use on pro. ... Sound 9,[100*SNDSCL\(2000 + LockLegs * 1000)]

Thanks for the heads up on the changes for the different angles. I will make sure to incorporate it.

@Laureatus

all the

serout p15,I8N1_38400, (5.3.0.0 IDE syntax)
must be changed to

serout p15,i38400,....... (all other IDE syntax)

Yes I changed mine to some defines like:

[code]
;Serial port to SSC32
SSC32 con P11
SSC32_BAUD con i38400

; Debug versions for SSC outputs
;SSC32 con S_OUT
;SSC32_BAUD con i57600
…
serout SSC32,SSC32_BAUD,"#",RRHH,RRHH2,“po4 #”…[/code]

Where I will change SSC32 back to P15 when I compile this for the ATOM. I also have at times used the debug version of it below, which allows me to capture all of the outputs that are sent to the SSC.

Thanks again

[laureatus]

Oh, as the “Distance = TmpDistance / 127” line is no more using the “(Index)” you can cut it from the for…next loop and paste it after the “next” of the loop like this :

for Index = 0 to 5 XPos(Index) = TmpXPos / 127 YPos(Index) = TmpYPos / 127 ZPos(Index) = TmpZPos / 127 next Distance = TmpDistance / 127

[kurte]

@Laureatus

about the sound command, you are using a version for BA IDE 5.3.0.0, this IDE is different than the 2.2.1.1, one of the differences is the sound syntax, it uses usec for duration instead of msec so, you’ll need to convert :
Sound 9,[100000(2000 + LockLegs * 1000)] into Sound 9,[100(2000 + LockLegs * 1000)]

and so on for all sound command from this 5.3.0.0 IDE version

By chance do you have any more information on other changes for this IDE? Or are you only going off of what is posted in the Basic Micro Forums, such as this post:
forums.basicmicro.net/ShowPost.aspx?PostID=18157

Thanks again

[kurte]

My repaired ATOM arrived yesterday , so today I was able to run the same base code on both the ATOM and the PRO and see what was going wrong with my atom pro code. I am using the latest IDE’s for both (5.3.0.1 and 8.0.0.0).

I started with the latest code ahr135n.bas… I made the changes to this code that I described previously in this subject. The code ran, but the position commands that were sent to the SSC32 were messed up.

So Today I started debugging the differences between the two processors. I found and resolved some problems and now the calculated positions are very close, so tomorrow I should have it walking properly on the Pro.

I am not sure if anyone else would be interested, but just in case I thought I would document some of the other things I changed.

1. The LONG type on the ATOM is signed where it is unsigned on the PRO. They have a type SLONG for signed long.

2. The SQR function has bugs. Some of the time it leaves the high bit on. The main place that this bit me was when TmpSEW was calculated. For example sometimes the SQR(17140) came back as 32898 instead of 130.

3. I ran into a divide by zero, near the ;H3. DCoord = SQR(…). If WCoord and ZCoord are both zero then DCoord will also be zero. The calculation of TmpCos divides by DCoord and two processors handled the divide by zero differently.

4. Minor point, but on my machine the first Serout in the function InitPos were to positions that were greater than the defined max or smaller then the defined minimum and on my robot this caused the hip vertical servo to hit the bottom of the bracket and when I was stepping through the code I found my servos were heating up.

That is all for now.

[docjones]

Hello Kurte, hi laureatus,

thanks for all that work! i just found the “eh3 templante.bas” and start rewriting it according to your notes.

Just a few questions:
Did you do something about that SQR(…) Bug? Do i need to clear high bit of the result if i am beyond a specific range?

regards
Marc

[kurte]

@DocJones

Just a few questions:
Did you do something about that SQR(…) Bug? Do i need to clear high bit of the result if i am beyond a specific range?

Hello and welcome.

I have been taking a diversion from my 3R Hex and playing with a BRAT . Unfortionatly I overwrote my last version of the Hex code with an older version . So I too will have to make some of the updates again. But yes I did need to clear the high bit. I did it simply like:

DCoord = SQR(WCoord * WCoord + ZCoord * ZCoord) & 0x7FFF ;bug

I will get back to my hex soon. But right now I am still working on code for the Brat. Things like using I2C to integrate an SRF08 or SRF10. Maybe a compass… All of this I will be taking back to the Hex.

Good Luck and let me know how you progress

[laureatus]

Unfortunately, i can’t help more about the 05.3.0.0 IDE version changes, it seems we have saw all the main changes anyway.

About the Pro version, you have found many tips and resolved many problems, it will help me too thanks !

i’m working on a “master” program for all H3 version (legs, body, control, IDE, Processor etc…), coming with a free Windows program, so, only one “master” program to download (easy for updating), and each customer build his specific Basic program according to his H3 robot, and some cool tools to adjust easily offsets…and more…

[docjones]

huh???

does that mean, i am the only one having a version that doesn’t run ? Actually: the code compiles, but i just worked approx 30 min on the code, so i need to update my wiring schema, i think. but i will keep you informed.

so far, i have added my SRF05 code to it and from linuxguy i took the IRPD code (this one is NOT tested yet).

i will PST.

regards
Marc

[linuxguy]

@DocJones

so far, i have added my SRF05 code to it and from linuxguy i took the IRPD code (this one is NOT tested yet).

You should be sure you have my latest code. I have not posted everything here and I don’t think Beth has posted my 1.3.0 code on the website. I’ve also just written and finished (completely tested) a nice little subroutine to read up to three Sharp GP2D12 IR Sensors, which will be in v1.4.0.

8-Dale

[docjones]

Hi!

actually, i am using the IDS 8.0.0.0 with parametrized gosubs … neat. (additionally, there is an #include <…> support, too!)

i think, by the time, i will post some libraries i developed.
Here is my plan:

• IPRD Lib
• PS2 Lib
• Movement Lib
• SRF05 Lib

all are heavyly based on code found in the forum

regards
M

PS: Feel free to email me actual/improved code versions to incooperate…

[sparticus]

Hi! I’ve been following this thread trying to make my Hex run on the Atom Pro, but have run into a problem–it doesn’t look like the Atom is successfully receiving any communication from the PS2 controller. I know Robo Dude is probably groaning at the topic by now, but I’m sure I’ve done everything that has been outlined. I’ve put the PS2 connectors on 12,13,14,15, I’ve switched the SSC data line to 11, and I’ve soldered on the 1K pullup resistor to pin 12. I converted the eh3r135n.bas according to the remarks that everyone has made and it compiled fine under IDS 8.0.0.0. I’m not entirely sure how to go about troubleshooting. As far as I can tell in the program during a debug, I’m stuck in the Ps2Query loop and the DS2Mode var isn’t changing no matter what buttons I’m pressing. I’m just starting to study the Atom Pro language so I’m not sure how to output debug info etc. I’ve got an old analog osc which doesn’t help a whole lot . . . especially since I have no experience on it. What more can I do in order to find out what’s going on? I’ve included some pics to help you see what I’ve done to the ABB. Thanks for any help you can provide!

-Michael

P.S. Does anyone know if I can get a new pot for an HS-475HB?

http://www.sparticustech.com/images/pull-up_resistor.jpg
http://www.sparticustech.com/images/connectors.jpg

[sparticus]

AHA!

Maybe I missed it somewhere in the forum, but I found the reason why I haven’t been able to get the PS2 controller to work. I should have seen this sooner…

In the ver 135 code that I downloaded it seems that the SEL and CLK pins are swapped!

DAT con P12 CMD con P13 CLK con P14 <--, SEL con P15 <--'

I fixed the code to

DAT con P12 CMD con P13 SEL con P14 CLK con P15

and now everything seems to be working! I don’t know how I missed that! I am now the proud owner of a hex running on an Atom Pro…