Kurt's Phoenix with Arc-32

Lynxmotion Legged Robots
81

Another quick update, in case Zenta gets a few minutes to play…

I think I have more of the code working now. I have added some additional support into the extras. You can now see and change EEPROM on both SSC-32 and Arc32. I finally got the sequences to run. I needed to add in some delays…

I first thought about adding an “R” command to allow you to see or change SSC-32 registers, I simply passed the whole string to the SSC-32 and did a serin with a timeout. If I receive a string back I print it… Changed it to be a little more general purpose and made it the “.” command. I pass everything after the . to the SSC-32. So you can now type in .PL0SQ0ONCE and it will run sequence 0…

I have done a little testing. I did a .R0=0<cr
This removed the usage of the SSC-32 offsets. I then used the Offset mode to generate new offsets that were saved away in the Arc32 EEPROM and then tried it out. I think it is working but I need to test it more.

I have also updated the download sequences code that can receive sequences from my VB app and save it to the SSC-32 EEPROM. I have not tested this part out yet, but I am probably the only one who used this anyway…

Will in the next day or so try configuring this code back to run without SSC-32 and try it on my phoenix.

Warning the configuration stuff is currently more like my CHR-3…

Kurt
Arc32 with SSC32.zip (49.6 KB)

82

Thats awesome Kurt! :smiley:

Thanks for sharing your work, I’ll give it a try as soon as I’ve solved some other stuff for Jim/James.
The offset part sounds interesting, looking forward to try it (and the GP player part).

I’ll let you know when I’ve done some testing.

83

Hi Kurt,

Certainly sounds like the right way to go (for the offsets).

I suspect they are. Not sure of how the Hitec servos are designed, but some designs I have seen are basically an analog comparator, The PWM charges a cap, and the voltage across it is compared with that of the pot. Add a little deadband, and the resultant error signal is sent to the amp to drive the motor.

I did just hear of a servo with an encoder built-in.

hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=14828&aff=8620

I wonder how much better it is? I don’t think they said what the resolution was. Could be an improvement!

Alan KM6VV

84

Just found last night:
letsmakerobots.com/node/18615

85

Thanks for the URL. Interesting project. I’d hate to spend all that on a cheap R/C servo 'tho…

I’ve used the AustriaMicro encoders here at work.

I’ve got C code to run encoders, I might just try driving the little DC motors in the R/C servos directly (especially since I fried the electronics on one of the GWS S03N 2BB R/C servos (they apparently don’t like 7.2v battery packs). Wheel Watchers provide a minimal ppr for encoders.

Alan KM6VV

86

I have not changed much of the code since the last posting. However what I have done was to change some of the CHR3_cfg, phoenix_cfg type files, to make it such that I could include both. I then put another file at the start config_cfg.bas at the start that had a set of defines that disabled the usage of one of the files as well as some other global stuff. That way I could simply change one define in this file and build for my CHR-3 with Arc32 and SSC-32 or my Phoenix with just the Arc32. I then built both versions and made sure that both robots appear to be able to walk…

I also verified with my Phoenix that it could still work with the PS2 controller. I left the code configured for the Arc32 with both Xbee and PS2.
Kurt
Arc32 with SSC32.zip (51.5 KB)

87

Hi Kurt,

The config file at the start was an interesting approach. Does this code also support the fastest SSC baud? I saw that you commented out the “i115200” part.
Would it be hard to make the code even more universal like supporting both BAP28/BB2 and the ARC-32 using the new config file to define that too?

Thanks for sharing!

88

I have thought about merging the merge again and maybe have BAP28 support again as well. Especially since I have combined both using the SSC-32 and without. The Bap28 version would not support the extras stuff as we don’t have a hardware serial port to talk to for S_IN/S_OUT and the bitbang functions and only S_IN/S_OUT sharing an IO pin makes it a pain… Also might continue with the XBEE only on hserial…

This version does not include any of my own Serial input/output functions yet so it currently does not support 115200. I could add that code back in as well, if you think you want the extra speed up. I just wish the standard serin/serout worked properly at those baud rates. I don’t know why they couldn’t but I have asked before and have tried it and they appear to output something closer to 125000, which I expect from HSEROUT, they have something like 173 clocks per bit so they should be able to handle it. But the new manual now says that the maximum baud rate on a BAP is 57600…

The other pain with merging back with BAP28, is all of the debug code has to change to do like:

#ifdef BASICATOMPRO28 serout s_out, i9600, ... #else hserout ... #endif
Which is a pain. I know I have mentioned this too many times as well. But I wish that:
Either Nathan defines a way for simple macros to be used, such that I could define one like: DEBUGOUTPUT, which either expands to
the serout, or the hserout depending on how I defined it. (Sounded like this may happen someday)

Or there is some hack like: serout -1,xxx would go to hserout1 and serout -2 would go to hserout2…

or better yet, a way to define a serial object that you can define the back end to be a hardware port or a software port, where you simply once call it to say set the baud mode data to X and it remembers it and uses the appropriate backend… This way you can simply abstract the differences away. This is what I use on most other platforms, but Nathan did not wish to embrace this idea. …

Let me know if the faster speed would help out here. Also if you do try this with the morph and 32 servos I will probably need to make a few fixes. Things like, me dump a sequence code needs to be updated to do more than two reads. Max read (EER command) of 32 bytes at a time.

Also I will put more of this code under ifdefs. For example the dump code and the download code could be optional to give back more code space…

Kurt

P.S - I do enjoy sharing code.

89

Real quick update on high speed. I know from the past that specifying a baud mode of i115200 did not work properly with the SSC-32. So I thought I would experiment a little. I know that I115200 compiles to 0x4011, where the high nibble of 4 is for the invert. the 0x11 or 17 is the number of .5us units of time that each bit takes.
That is 2000000/115200 = 17.36… As I mentioned before the 115200 appeared to actually output at 125000 (at least according to my logic analyzer), So I decided to try a baud mode of: 0x4012, with a real simple test program:

Main: serout P16, I115200, "ABCDEFGabcdefg0123456789"] serout p17, 0x4012, "ABCDEFGabcdefg0123456789"] pause 20 goto main
The logic analyzer again said that P16 had a baud calculated at 125000 and it had P17 calculated as 117647, if I tell it to use the baud rate of 115200, it still properly identifies all of the characters that were output. I also modified the program to instead use 0x4013, the auto-baud feature guessed the baud as: 111111. If I manually told it to use 115200, it again showed the right characters, but I noticed that where the analyzer said the sample locations was appeared to be closer to edges (more likely for errors).

So next step is to try recompiling the CHR3 with SSC-32 with cSSC_BAUD set to 0x4012 and change the jumpers and see if it works…

Kurt

Update: I updated the CHR3 as I mentioned and it appears to work with the baud mode I mentioned above… :smiley:

90

Thats great Kurt. I know there is a difference in clock speed between the BAP28 and BAP40/ARC-32 does that also affect the possibility to use higher (or diffferent) baud rate to the SSC? I’m just asking since I thought you tried this method before on the BAP28 too? Does the 0x4012 appear to be reliable over time, without any hick-ups? If so, thats great news!

Yes, I’m planning to use this ARC+SSC code as a base code for MorpHex. I’m thinking that faster is better, especially when commanding 31 servos at ones. If I’m going to use the GP player on MorpHex I’ll probably just play the sequence. I’m not sure if I’ll ever need the “dump sequence part”.
:unamused: hmm wait, I was just thinking. Is it possible to read all the servo positions from the last step (or the first) in a sequence? And then maybe do a FK to get the actual coordinates so that the IK code can place the feet at the same spot just before and after doing a GP sequence. just a thought…

91

Hi Zenta, I tried running the simple program again this morning on both an Arc32 as well as a Bap28. This time I ran the Analyzer at 16mhz samples and on both Baps, it generated the same baud rate of 116788 (which is off from 115200 by maybe 1.3%), which I believe is in the acceptable range. It like the pulses ranged from 8.5us to 8.625us and the probable sample points appeared to be well within the area between transitions. So I think it should work on both platforms.

It would be great if someone with a Bap28/SSC-32 Hex tried it out. All you need to do is change the define and recompile/download and update the jumper on the SSC-32. Combining this with the Binary mode gives a pretty good boost in the download speed to the SSC-32 (8/3 avg chars per servo) (3 * baud rate) or about 8 time faster!

Yep the dump code was more important for me, as I am writing my own download code as well as sequence emulation on Arc32 only code, so seeing what is saved in the EEPROM of the SSC-32 was important. Not sure if others will be interested in downloading sequences to the SSC-32 while your code is still running and without any wiring changes or not, but I will probably make it work and probably conditional in the code.

Yep, it would be reasonably easy for me to get the position data for the last step, and I suspect that it would not be hard for you to calculate the FK.

Kurt

92

Is the latest version of Xan’s Phoenix software v21 (found in Arc32 Phoenix Checkpoint.zip, newest file dated 2010-04-07) ?
Good to know before I start using it…

93

ok, then i’m try to run on this code

I changed so the setup sutes my needs:

;--------------------------------------------------------------------
USEPS2 con 1 ; Do we use the PS2?
;USEXBEE con 1 ; and/or do we use XBEE?
;USERC con 1 ; and/or do we use RC
;--------------------------------------------------------------------

And then i tried to compile … no luck (win7/64b + Studio 2.0.0.7) but the errors where easy to solve:

First compile error:
Error: PHOENIX_ARC32_EXTRAS.BAS(LINE 81) : [TOKEN _RXP_CHECKFORHEADER_TO] : Unexpected token after IF command

This semes to be because there are a reference to _RXP_CHECKFORHEADER_TO and this is in phoenix_control_diy-xbee.bas, and i am not using XBEE
phoenix_control_diy-xbee.bas(1422): _RXP_CHECKFORHEADER_TO:

I solved it whith a simple
#ifdef USEXBEE
if (hserinnext 0x81) = -1 then _RXP_CHECKFORHEADER_TO
#endif
… maby this if/endif shold be wider … but this is enough to compile

Second error:
Error: PHOENIX_ARC32_EXTRAS.BAS(LINE 520) : [TOKEN I] : Expected variable

I solved it by adding
i var byte

94

Thanks, yes the first ifdef looks correct.

The issue with the undefined variable I, shows a very strong reason why I wish there was some form of scoping in this basic. If you define I here and then turn back on use xbee it won’t compile. The better thing to do is to remove it’s definition from the XBEE file and move it into the main variable definitions in the main source file. I have done that now in my version…

Sorry
Kurt

95

Yes that is a better way to do it

96

Hello Zenta and others…

I thought I would do an update post here with my Arc32 phoenix code. This code includes the part that allows it to compile and run with or without an SSC-32. Also it will compile for a Bap28 with an SSC-32. It also has multiple configuration files with a file to say which one to use.

The XBee code in here was updated to continuously query the DIY receiver without waiting for the controller to say something changed.
A lot of these changes are under the ifdef:
#ifdef XBEE_NEW_DATA_ONLY

But there were a couple of other changes associated with it.

In the function: InitController the following line was added:
fSendOnlyNewMode = 0 ; default to query mode.
It may not have been necessary as it was probably init to zero anyway.

In the function: ReceiveXBeePacket

This section changed:

; see if we have an outstanding request out and if it timed out... if _fReqDataPacketSent then if (((_lCurrentTimeT-_lTimerLastRequest) * WTIMERTICSPERMSMUL) / WTIMERTICSPERMSDIV) > CXBEEPACKETTIMEOUTMS then ; packet request timed out, force a new attempt. _fNewPacketAvail = 1 ; make sure it requests a new one _fReqDataPacketSent = 0 ; turn off that we sent it ****NEW***** toggle P44 endif endif
Probably should have deleted the toggle P44… (Debug code). Above I marked the line with NEW which is not in the code.

Also a little down from there changed the code to look like:

if ((fSendOnlyNewMode = 0) or (fSendOnlyNewMode and _fNewPacketAvail)) then ; Now send out a prompt request to the transmitter: if _fReqDataPacketSent = 0 then gosub SendXBeePacket [_wTransmitterDL, XBEE_RECV_REQ_DATA, 0, 0] ; Request data Prompt (CmdType, ChkSum, Packet Number, CB extra data) _fReqDataPacketSent = 1 ; ; yes we have already sent one. GOSUB GetCurrentTime], _lTimerLastRequest ; use current time to take care of delays... endif endif
The ifdef fReqDataPacketSent… was added. so that I would not continuously send out requests, if one had already been sent and it had not timed out…

Hope that makes sense.

Kurt
Edit: Removed the zip file, posted one that does not hang later…

97

good work

98

just so you know

if i compile it al just as it is in the Zip, it all works fine
but if i add
;USEXBEE
i get
Error: FILE \PHOENIX_V21.BAS(LINE 670) : [TOKEN XBEEOUTPUTVAL] : Expected Label

but it is easy to fix

99

Hi Kurt,

Just to be sure… Did you test your latest code running on ARC-32 only + XBee ? I just can’t get it to work. No response on the “0” button. The terminal (servo offset part) work though.

100

I did awhile ago, I will will try to do it again in next day or so. I wonder if the issue is the packet size. That is your data packets are bigger than min. ie did you update the setting:
XBEEPACKETSIZE con 8

Just a thought.

Kurt