Sure, rub it in!
Alan KM6VV
I will second that! 
Kurt
These aren’t going to replace the SSC-32 anytime soon, are they? 
The SSC-32 will not be replaced by the ARC-32. The ARC-32 will replace the Bot Board II / Atom Pro 28, -and it will replace the SSC-32 / Bot Board II / Atom Pro 28 combination. The SSC-32 will remain the main controller for the arms. If there are any projects developed for an arm that takes advantage of the ARC-32 features we may package arm kits with it though.
Any release date yet???
Attached is my modified phoenix code for BH3-R with ARC-32 board.
For those looking for the group move equivilent using HSERVO see the very bottom of the code. I use one HSERVO command to handle all the servo movement.
Also I see there was confusion on HSERVO syntax. There is NO HSERVO2 command. If you use ENABLEHSERVO2 then HSERVO works with the hardware pulse generators. If you use ENABLEHSERVO then HSERVO uses software interrutps to generate servo pulses.
So only ENABLEHSERVO2 is new. HSERVO command uses hardware pulse generators if using ENABLEHSERVO2 or uses software interrupts if using ENABLEHSERVO.
HSERVOWAIT command works with either.
GETHSERVO command is GONE. It’s been replaced by a function. The new functions are:
HSERVOPOS pin
HSERVOSTATE pin
HSERVOIDLE pin
HSERVOPOS returns the servo pins current position. For example:
if( hservopos(p0) > 1000 )then
;do something
endif
HSERVOSTATE returns the ANALOG value of the servo pin specified if that pin supports A/D.
HSERVOIDLE returns a 0 or not 0 depending on if the specified servo pin is idle(eg the servo is done moving).
Note that these new functions also work with the odl ENABLEHSERVO system.
arc32-bh3-r-3.0.test.bas (41.2 KB)
Wow thanks Nathan!!!
Thanks for sharing!!
Looking forward to study your version of the code for the ARC-32.
Hi Kurt,
I just chatted with Dale. You’re on the list to get one. They are making more.
Sounds good. Keeping busy with other stuff until then. May have to purchase the phoenix legs and 6 more servos to try this out. (Have phoenix body kit and 12 645s)…
Kurt
Hi Nathan,
I’ve been looking at your code and I’m impressed how elegant you solved the group move command with only one HSERVO command! 8)
For understanding how this group move worked I used some easy values:
Servo1, startpos=0, newpos=1000
Servo2, startpos=0, newpos=2000
Lets say the Time=200
This should give Servo1 a speed= 1000*20/200= 100
And for Servo2 a speed= 200.
Meaning that Servo2 needs to move twice the speed than Servo1.
Did I get it right? Are the speed variable in the HSERVO linear all the way, and what range does the speed variable accept? byte or word limited? The manual say the speed are default to 255 does that mean it only accept values from 0-255? Is that accurate enough?
In your phoenix code you doesn’t seem to use any calibration offsets for each servo/joint. Did you manage to mount all servos to the 1500=0deg positions? How accurate are your StepsPerDegree = 200? Did you do any test/measurings for setting that value?
I liked how you set the BodyDimensions (Offsets), very smart way to do it for a circular body!
Hi Zenta,
I am pretty sure that the default speed is just that and probably is not a limit. This is the amount to add to the servo value on each 20ms pass of the servos. i.e. for each time the servo pulse is generated, the code generates the current pulse and then increments the pulse width for the next pass through by that amount. Also note that the HSERVO values are in Clock Ticks.
So you are right for this move the speeds would be 100 and 200. As I mentioned I think the code simply does this linearly. I don’t think there any ramp ups/downs or any understanding on how these values are used by the servo.
Also I believe that any round off issues are taken care of on the final increment. That is, suppose that instead of the new values you had a difference of:
2000 and 1755 then the first speed is easy still: 200, the second would be 175.5 (so round up or down). So for now lets round down and pass in 175, so by the 10th pass through you would be off by 5 clocks, which as this is the end point, I believe that HSERVO will than adjust to right value. My guess is that you could not tell the difference of the pulse width that was off by (5/20)uS.
I hope this makes sense.
Kurt
Thanks for the clarification Kurt!
It sure make sense. It sounds logic that the speed factor is more than a byte size.
At the moment I’m not sure what to play with; my next robot project, DIY remote stuff or the ARC-32… 
I just wish I had more free time for all the fun stuff!
Kurte pretty much got it on the nose. The speed argumetn is how far to increment from the current postion per 20ms cycle. The servo pulse is in clock cycles centered at 1.5ms. For a servo that has a 1ms pulse range(most digital servos are like this) you can move ± .5ms which equals ±20000. To move from -20000 to +20000 in 5 seconds your speed would need to be 40000*20/5000.
40000 distance * 20ms cycle rate / 5000ms time = 160 distance per 20ms cycle
There is no ramp up or ramp down and if the next position increment crosses the final position the final position is set instead. At this point if you use HservoIdle you would get a non-0 value because the servo is now idle. You can also setup interrupts to trigger when a specific servo goes idle.
The servo interrupts are:
HSERVOINT_SERVO# where # is 0 to 31
They can be used with ONASMINTERRUPT or ONINTERRUPT. If you use ONASMINTERRUPT REMEMBER to save/restore any trashed registers.
I figure with the interrupt system you could implement a reasonable accel/deccel system. It should also lend itself to background processing of leg movement handler routines. You can call HSERVO inside the BASIC interrupts to set the next position to move to. It’s a little more work to do it in the ASM interrupt handler.
;r5 = rate
;r4 = position
;r0 = servo number
shll.w r0 ;times 2 for table offset
add.w #_SERVOTBL,r0 ;calc table data address
mov.w @er0,r0 ;get table data
xor.b r0h,r0h ;isolate servo index
shll.w r0 ;Multiply index by 2
and.w #0x3E,r0 ;limit index
add.w #30000,r4
mov.w r5,@(_HSERVORATE:16,er0)
mov.w r4,@(_HSERVONEWPOS:16,er0)
Yes, it looks like you understand it pretty well. And yes HSERVO is linear(as long as the servo). Speed range is word limited. The manual is out of date. The speed default is 0 which is infinite. A 0 speed will just set the new position immediately.
For the most part I was able to get all my servos mounted at the center point. Close enough for horse shoes anyway. 
I just measured with Mark I eyeball on the steps per degrees.
Thanks Nathan, cant wait to try one out. Although like Zenta I do have plenty of things to do…
Yep that is a very hard choice to make. It would be great to see a new generation of the DIY remote that others can build that is controlling one of your current creations that is running on an Arc32. Could you have that all done by tomorrow? Of course I would also love to see your next robot project (whatever that may turn out to be )
Kurt
Thanks for the information Nathan!
I just had to test the group move using a single HSERVO command like you did, using a simple program. It worked perfect! And I just had to test how accurate your StepsPerDegree = 200 was… 
Since I don’t have a protractor like this.I decided to make a simple servo protractor using a cheap (but accurate) protractor like this:
It didn’t cost more than about 37 NOK or about 6,20 USD.
I drilled out the center hole on the protractor disc with a 5,8mm drill so that it fit accurate over the servo spline. Then cut of the ruler part from the protractor marker/pin, increased the hole on the marker with a 9mm drill and glued (epoxy) the blue servo arm onto it. I’m also using two simple door magnets to fix the protactor disc onto the servo. The magnets make it easy to adjust the center point (90 deg mark).
A picture showing how the magnets fix the protactor onto the servo:
Ok, back to the test.
I tested two brand (right out of the box) new HS-645MG servos. With the StepsPerDegree = 200 the result was almost “perfect” They where just a little bit of. This picture show a 90 deg cw rotation:
Adjusted the StepsPerDegree = 201 and the result got even better:
I did test different angle values and like I’ve seen before the linearity of the servos isn’t perfect and the result can also vary a bit cw vs ccw.
Anyway, I believe using the 200 or 201 StepsPerDegree should give a very good result.
Oh, another Q to you Nathan:
I saw how you assigned the pin to each servos:
[code];[PIN NUMBERS]
LRCoxaPin con P13 ;Rear Right leg Hip Horizontal
LRFemurPin con P14 ;Rear Right leg Hip Vertical
LRTibiaPin con P15 ;Rear Right leg Knee
LMCoxaPin con P10 ;Middle Right leg Hip Horizontal
LMFemurPin con P11 ;Middle Right leg Hip Vertical
LMTibiaPin con P12 ;Middle Right leg Knee
LFCoxaPin con P9 ;Front Right leg Hip Horizontal
LFFemurPin con P8 ;Front Right leg Hip Vertical
LFTibiaPin con P0 ;Front Right leg Knee
RRCoxaPin con P29 ;Rear Left leg Hip Horizontal
RRFemurPin con P30 ;Rear Left leg Hip Vertical
RRTibiaPin con P31 ;Rear Left leg Knee
RMCoxaPin con P26 ;Middle Left leg Hip Horizontal
RMFemurPin con P27 ;Middle Left leg Hip Vertical
RMTibiaPin con P28 ;Middle Left leg Knee
RFCoxaPin con P25 ;Front Left leg Hip Horizontal
RFFemurPin con P24 ;Front Left leg Hip Vertical
RFTibiaPin con P16 ;Front Left leg Knee[/code]
May I ask if there are any reason for the LF leg uses P0,P8,P9 and not P0,P1,P2, Or why the RF uses P16,P24,P25?
Just a coincidence?
I don’t want to say much more about it but I’m gonna use the ARC-32 on it. I’m just not sure how to make the XBee work with it yet. I hope there are some 3,3v output pin on the ARC-32 too for the RTS line…?
But if you look very close to this picture of my messy and very small workshop you can see some parts of my next robot project.
I love your workshop. Currently I don’t have anything except for my office… Some day I will need to setup a workbench someplace…
As for hooking an XBEE up to the Arc32, I would probably check whichever pins are currently used for I2C (SCL/SDA). To be safe in my last order to Sparkfun I ordered a few of these: sparkfun.com/commerce/produc … ts_id=8745. I am hoping that they would be sufficient for the Arc32 boards. But I may also buy a couple more of the selmaware Xbee adapters as for some reason the Sparkfun ones dont work with my AVR systems…
Kurt
Edit: I will need to get my hands onto the Arc32 to give you more information. My guess is that we will want to use the HSERVO type support. The problem may be that assuming that the pinouts are similar to the BAP40, then the main hardware serial port that is not associated with S_in/S_out is HSERIAL2. So everywhere in the code that does things like: HSERIN has to be changed to HSERIN2… I had a version of it running with my BAP40 that I may need to digup. However the code looked real messy with #ifDEF BAP40 …
Maybe we are lucky and they redid the pinouts such that HSERIAL is more easily available…
The pins I used for the robot legs was purely cable length limited. I didn’t have any servo extension cables so I put them to the pins the servo cables would reach. If I had the extensions I would have left a group of 8 pins empty so I could have those pins be 5v. The 32 servo pins are grouped 4x8. Each group of 8 can be powered from VL or VS.
S_IN and S_OUT are HSERIAL. HSERVIAL2 is on the AUX header. I may be able to add a way to swap this by a define though.
Nice workshop! I see a small green lathe in the background. Cool! I have plans to build a work bench that I designed in via cad. It’s nothing fancy. After 10 years living in my 2nd home I figure the kitchen table is no longer sufficient. My first house had a workbench that I got rid of, thinking I would build a new one, why it took me 10 years to get around to it, I’ll never know.