Which pins specifically? or rather, where in the .bas would I find the pin definitions? right now I’ve got it set up in what I would guess you would have it, but it won’t work unless it exactly the same right? I search for “43” and everything that comes up is in your sintable…
edit: something tells me I’m missing a config file… Does BMide support multiple files for a single program?
It is defined in phoenix_control_ps2.bas.
[PS2 Controller Constants]
PS2DAT con P40 ;PS2 Controller DAT (Brown)
PS2CMD con P41 ;PS2 controller CMD (Orange)
PS2SEL con P42 ;PS2 Controller SEL (Blue)
PS2CLK con P43 ;PS2 Controller CLK (White)
Kurt
Oh I see, I was merely opening the main phoenix file, not the .prj
As I understand it, to configure this for a custom robot, you need to set the Min and Max values for every servo, and the lengths of each of the limbs, and the default position. What are the offsets? is that like if you have the limbs offset at a joint?
So, how does one go about finding all of these value? aside from length, that shouldn’t be too hard
also, is there anything else that needs to be configured?
Since I have had a few inquiries into the phoenix code running on the Arc32 that still uses the SSC-32, I thought I would post it here…
Please note: this is a Work in progress. That is I was playing around with the contact switches to see which approach works better for detecting where the leg is when it makes contact… Also had code in that tries to make the legs be more vertical at whatever the current body height is when you press the “9” key on the DIY remote…
Again those parts are still in the experiment mode…
Phoenix on Arc32 with SSC-32.zip (57.9 KB)
Thanks for sharing Kurt!
I’m just wondering, how did you solve the servo offset when using the ARC-32/SSC-32 combo, did you use the offset register in the SSC-32 or the offset in the ARC-32 code?
I would have to look, but I believe that I just used the SSC-32 offsets for this. We could pull in the code from the other Arc32 port that kept them in the Arc32s EEPROM if that is desired to give larger offsets…) But I have been trying to go with the official way and pull the horn off of the servo position it close enough and put it back on, such that I am within the range of the SSC-32 offsets.
Kurt
Ok, the standard register offset won’t do the job in my next project (without snapping out the horn though). What I really liked with you ARC-32 code was how easy it was to calibrate each servos, simply brilliant Kurt!
Thanks Zenta,
We have a couple of options here, one is to see if we could get a version of the SSC-32 firmware with the offset restrictions relaxed, which I understand why Jim is hesitant to do so.
Probably better would be for me to merge the two versions. That is I could go from the first Arc32 version I had that was using HSERVO system and make it optionally go back to the SSC-32. Would not be overly difficult. Things that we would need to change include:
a) ServoDriverStart/Commit - easy just use the code from the other version, except apply our stored offsets. Likewise for the timing code…
b) Calculate offset code, should be easy to change the hservo there to serial outputs… Not difficult
c) What do do with Sequences:
c1) simply let the SSC-32do it, knowing that no offsets will be use.
c2) Use the Arc32 emulation I did earlier, but then have the output generate SSC-32 commands to do it…
I think that would be about it… What do you think? Should we try it?
Kurt
Hi Kurt,
This sounds like a good idea! (as long as it allow large offset values (pwm values)).
Personally I would prefer using the SSC-32 GP player. As long as the servos are calibrated correctly in the Visual Sequencer (SSC-32 configuration) there is no need for register offset, so that should be ok. The only thing is that you’ve to calibrate the servos two times, both in the ARC-32 code and the Visual Seq. It would be very useful if the actual offset value stored in the ARC code could be easily displayed in the startup terminal mode. If I remember correctly when playing with Archer this was possible in the “set offset” feature.
That would be fun! 
Hi Kurt,
I’ve been looking at your ARC/SSC combo code.
I guess the Enable_TA part is for your attempt to do Terrain Adaption?
If so, I’m wondering why you have this definition in the start of the code:
[code]#ifdef ENABLE_TA
awSSCCoxaAngle var word(6) ;! Values we sent to SSC
awSSCFemurAngle var word(6) ; !
awSSCTibiaAngle var word(6) ;
awSSCCoxaAnglePrev var word(6) ;! Prevous values
awSSCFemurAnglePrev var word(6) ; !
awSSCTibiaAnglePrev var word(6) ;
awSSCCoxaAnglePend var word(6) ;! Prevous values
awSSCFemurAnglePend var word(6) ; !
awSSCTibiaAnglePend var word(6) ;
#endif[/code]
I was thinking not to use the Enable_TA part at this moment. In the ServoDriver section only the awSSCXxxxAnglePend variables are used under the SSC-Binary definition. My problem is if I choose not to define the Enable_TA these variables isn’t defined anymore. I guess this could simply be solved by removing the #ifdef,#endif lines in the code above.
Any suggestions?
Hi Zenta,
Last night I was in the process of merging some of that stuff into the other code base…
To get the current code base to compile, you can simply move these variables out of the ifdef
awSSCCoxaAnglePend var word(6) ;! Prevous values
awSSCFemurAnglePend var word(6) ; !
awSSCTibiaAnglePend var word(6) ;Or could have another ifdef inside the servodriver that simply uses a word variable (not an array) as you don’t need to save these values away…
Kurt
I have given this serious thought, but I am sorry to say, it’s not going to happen. The fact is this request goes well beyond the original intent of the position offset. It has the potential of severely limiting the range of the servo when implemented. These larger offsets should not be handled in the SSC-32’s firmware. They should be handled in the hosts code. 
Thanks Kurt,
I’ll try that later, using only word variable should save some space too.
I agree with Jim here, ex. setting the registry offset to 400 means that when sending a 1500 command to the SSC would in reality send a 1900 value to the servo. I do see that this can make thing very messy if you don’t pay attention to it. Using more “visible” offsets in the host code is probably a better way, anyway.
Hi Zenta (and others)
Well I now have the Arc32 back on my CHR-3 (instead of the Propeller or the Arduino Mega) and I am now starting to debug the new integration of the SSC-32 servo driving into my Arc32 version of the phoenix code that I did that used HSERVO…
I have the code in to read in my own version of the offsets, which are added on during the servo driver. I also had to add in the code that uses an IO pin to the XBee to tell it not to send data. Needed this as the HSERIAL interrupts was corrupting the output to the SSC-32. I have the main code working for walking and the like. But the running of sequences appears to be hanging the SSC-32 for some reason (PL0SQ0ONCE), which I need to debug. I am now working on the Extras file, that handles the keyboard interface. It still works for dumping EEPROM data on the Arc32. I have the code converted so it can dump a sequence that is stored on the SSC-32. May also add dumping for EEPROM data as well.
Next up is to debug the servo offset functions that allow you to interactively figure out the zero points. Would post code up here, but first want to get a few more things working.
Kurt
Ah! you’ve come back to the fold!
Good to see you working on the CH3 w/ ARC-32. Will you be supplying a PS2 code module as well?
Good work!
Alan KM6VV
Yep, having fun again. right now working on the extras stuff on the Arc32 with an SSC-32. So far I have it dumping/editing EEPROM on the Arc32 and SSC-32. Also have the ability to view/change SSC-32 registers. (Why - because I will now turn off the offsets and then use the offset data I store on the Arc32 that is not limited…", when I go back to other processors I will simply turn this back on (r0=…).
Will then re-zero my servos and make sure my offset code is working.
Also I had code that allowed me to use VB to download sequences to the Arc32 EEProm which I then did enough emulation to run the sequences. Now in process of maybe updating the download code to save to SSC-32…
Yep, I had this working long ago, will probably make sure it still does… I use the Aux connector that has pull-ups on the four signals.
Thats all for now
Kurt
Do you really need the SSC-32 with the ARC-32? Have you been able to compare the main cycle time for both?
Being able to get at the SSC-32 registers from the ARC-32 I/O will be useful.
Still not clear on the advantages/disadvantages of having the offsets in SSC vs BBII or ARC.
I like the idea of being able to “adjust” while in the ARC-32 program!
But I’m busy with some side-projects. I’d hoped for more response on the 1425CR R/C servos, guess they aren’t being used much yet. I’ll have to wait for Christmas.
Alan KM6VV
Do you need an SSC-32 with Arc32? The simple answer is No. My first port of the phoenix to the arc32 does not use an SSC-32. I like this arrangement as then I don’t have to worry about the serial stream to the SSC-32 being corrupted by anything that generates interrupts, like the HSERVO, HSerial, … But I started playing around with having it connected to the SSC-32 as well, as I was experimenting with the foot contacts and I ran out of code space on the Bap28 and so I simply popped on an Arc32 board instead which added a lot of code space. Also it was easier to debug on these processors as S_IN/S_OUT are on hardware serial port, so I could output stuff and actually see it in a readable non-corrupted stream. I was too lazy to tear apart the CHR-3 to bring all of the servo wires out to the SSC-32, especially since I like to experiment with other processor boards as well…
Again I was doing it for those reasons, but then Zenta showed some interest in this arrangement as well. It probably has something to do with his current project, which I currently count 31 servos, which if they were all connected up to the Arc32, there probably would not be much room left to plug in anything else.
Using the servo offsets on the SSC-32 works well for what it was intended for, which is you rotate the servo horn to be as close as possible to horizontal or vertical and then you use the offsets to get you there. As such they are limited to ±100. However sometimes some of our configurations are such that it forces you to take off every servo horn and move them by 1 or 2 clicks to make it work. Sometimes in our code we simply want to cheat and get the same effect but not have to change the servo horns. So my offset code currently limits it to something like ±300. If this is not enough you can always change this to whatever works for you. The disadvantage here is that with this approach you end up not having the same ± range on the servo. That is if you moved it in one direction by +250. You may only be able to move it another 250 in that direction before you hit the stops, but can move it maybe 750 in the other direction. To me this is not much of an issue as I will typically have physical limits the servo can move anyway and have those limits in the code…
Yep, I have had some form of servo offset code in several of my programs in the past. I will often do this if I have room and I am on a processor that has a hardware serial port on the terminal (S_IN/S_OUT) as I can easily add in code to see if a character has been received without much overhead on the program. I like doing this as I am often either too lazy or in too much of a hurry to do it properly when I am building or reconfiguring a robot.
Kurt
OK, I can see that you’ve got both because of the way you’re experimenting (swapping controllers), that makes sense. Code could thus be interchangeable, with just a #define (con) to select the code needed.
I do like having the hardware serial ports for all but the most simplistic project.
On your extended offset range, seems like that would affect the scaling as well. Maybe not. But a few comments defining the “type” of correction would certainly be appreciated. I forget things really fast…
I suppose there is a code trade-off for the offsets? Letting the SSC-32 handle them saves computations. I like the idea of downloading them from the controller into the SSC-32, although that idea wasn’t particularly accepted. Anything for offsets in the ARC-32? I don’t remember any registers set aside for this. that would make code more portable between both systems (w/ and without SSC-32).
Alan KM6VV
Yep - I do like to try different things out, so only having to change a couple of wires is a real plus. At some point I may want to setup another Hex, that I maybe extend all of the servo wires out to above the deck and label them, such that I can plug in a new Microcontroller and more easily such that I can experiment with having them handle the servos natively as well. I also have the my phoenix with the Arc32, but I like to keep this one in one piece. It is nice to have one to demonstrate on and to compare other builds against…
Dito. But the Bap28 only has 1 and the Arc32/Bap40 only has 2 and 1 is the one we use to program the board with and debug stuff… So When you have something like an Xbee and an SSC-32 or the like one of them needs to be bit-bang… That is where the Arduino Mega or other ATMega1280 based boards with 4 usarts is real nice. The propeller works well there as well as while the serial stuff is bit/banged out, you simply dedicate a COG to it and once it is properly coded up, things you do in other COGS does not negatively impact on it.
I guess that depends on if the servos are significantly non-linear.
Yep, It is always a good idea to document things like this.
Yep. There is a little overhead in the servo driver code that I do an add of the appropriate offset for that servo. However the way I have the code organized that we output the majority of the next move before we wait for the previous command to complete and only output commit string at that time ( for normal builds, or the three byte binary time command for binary mode> Most of the extra time is not used anyway, except maybe by Zentas or Xans new code that do a lot of small sub-moves. No the Arc32 does not have any dedicated offsets built-in.
That is all for now.
Kurt