Yep by default XBee work in a terminal replacement mode. You have to use special ways to get into a command mode where you set the destination you wish to talk to…
In API mode you compose packets of data, where you set the destination in the packet as well as some other information like size of the data and a checksum. So in my pre-api mode, I was creating my own packets with sizes and checksums and the like, which than the XBEE wrapped up in it’s own packets and sent it to the other side that unwrapped the XBEE packet and gave me a stream of data. I then had to do the work to verify I got the proper start of a packet and extract the data…
Also I nice point with API mode is I can have the robot set up for multiple destinations. One to talk to the remote and another to send to the PC for debug information…
Here is my latest update on the T-Hex and Phoenix code. They share all the files but different .cfg files. I did try to use the ServoDriverStart and ServoDriverCommit like Kurt did, not sure if I got it 100% correct. (Kurt, would you mind to take a look?) The code work fine for XBee (API) though, didn’t test it using PS2 but I think that should work fine.
I took a quick look through and it looks good to me, I also tried compiling for both Bap28 and Arc32 and that works. Have not tried running it yet, may try later with the phoenix with Arc32…
My phoenix is powered by only an Arc32. My CHR-3 is sort-of a chameleon , it always has an SSC-32. As I play around I change what is sending the signals to the SSC-32. Currently it is using an Arc32. It originally had a Bap28, it has also had a propeller and it has had an Arduino Mega. I may soon put the Mega back on it as there was some issues with the code running with the latest Arduino IDE…
I guess a real question is, should I re-merge back in some of the other changes I made to the previous set of T-Hex code I posted, that had two versions of the ServoDriver. One that uses an SSC-32 and a second that outputs HSERVO commands… I did run that version on my actual phoenix…
I’m not sure if I follow you, did you post a code that supported both HSERVO commands and SSC-32? I must have missed that , where did you post it? I do like your ARC-32 version, especially the “extra” stuff with the servo offset feature, did you merge that to?
BTW, all my robots are now working with the XBee API code. Archer uses a hacked version of your ARC-32 phoenix code. I kept running out of memory space for A-pod so I had to remove some parts. Actually I’ve been thinking of replacing the two (BB2+SSC-32) boards with ARC-32 on A-Pod for two reasons: Saving weight and more memory space.
This is the full phoenix with Arc32 code base with all of the extras, plus it had multiple configuration options including the option to use an SSC-32…
Awesome Kurt, I totally missed that one. It’s getting messy with all the different code versions, I wish there was a better system for organizing the different versions on the forum. Maybe a thread just for code updates or something? Not spread all over many different threads.
Another thing I’ve been thinking on: With all the #ifdef’s in the code, I wish that the Studio IDE had a better way to display what part of the code that was active under compiling. Maybe the non-active code could be grayed out? Is that possible? Just a thought…
I know what you mean, that is why I started playing with merging versions which is why I made the version I mentioned in the previous post. Hopefully I will get inspired and merge that also with the THex stuff for 4dof/3dof and mixed…
We almost need something like a sourceforge or other source control system to keeping the different versions… Or maybe something like the Propeller Object Exchange… Something like this would be good also to handle issues like finding updates to programs that are mentioned in different tutorials, that need to be updated due to changes in the IDE or the like…
Yep, that would be nice. At times the variables mentioned in the ifdef will be color coded showing if it is defined or not, but I find when it goes to multiple files or if the define is defined within an ifdef that accurate, especially in multi-file projects… Maybe Nathan could do something…
Just jumping in here to say, I’m looking into this. I can’t make any promises, but a system like you’re suggesting would make a lot of things convenient. I’ll let you know when I have some definite information.
Yesterday I had a robotic course and demonstration at two local libraries. Everything went well except for one thing that I had forgot to test.
The GP player didn’t work on Phoenix.
I’ve done some debugging. My SSC32 works fine from Visual SEQ, all GP sequences run fine. The first thing I noticed is that the DIY remote displayed the message: “Seq Disabled” which mean that the GPEnable=0.
[code]GetSSCVersion:
serin cSSC_IN, cSSC_BAUD, 1000, timeout, [GPVerData(Index)]
Index = (Index+1)//3 ; shift last 3 chars in data
goto GetSSCVersion
timeout:
if (GPVerData(0) + GPVerData(1) + GPVerData(2)) = 164 then ; Check if the last 3 chars are G(71) P(80) cr(13)
GPEnable = 1
else
sound cSound, [40\5000,40\5000]
endif[/code]
For some reason all the GPverData (0-2) return 0.?
I’m using GP firmware of course. I’ve also updated the firmware.
I did also try to set the GPEnable to 1 just for a temporary override but the sequences won’t run.
Have you tested the GP part on your code lately, Kurt?
I will take a look. This was actually some of the original code. The only thing I did was add some additional stuff into the DIY to check the state. In addition I added code to verify a sequence exists (location on SSC-32 EEPROM not equal to 0000 or FFFF) and not try to run …
As I suspected, the timeout for reading in the SSC version is too short. It is only 500us, which is timing out… I tried in test program as my phoenix and CHR-3 currently both have Arc32’s on them. My phoenix has no SSC-32 and does it’s own emulation…
When I cut and pasted the code from current phoenix code, which matched yours, it was timing out. When I changed the serin to be:
serin cSSC_IN, cSSC_BAUD, 200000, TO_GPWAIT, [GPStatSeq, GPStatFromStep, GPStatToStep, GPStatTime]
Then it worked and said I had a GP player. Tried with 2.0.4GP and later with the 2.05 EGP…
Not sure why if you hard coded GPEnable=1 why running a sequence did not work. I only had 1 sequence on the SSC-32 sitting on my desk and it appeared like it would run the sequence (I only have 1 servo just plugged into it…) The GPPlayer code in the earlier had no timeout on the serin. The latest code I saw from your T-Hex project had a timeout, but it was rather large:
GPWait:
pause 100
disable TIMERINT
serout cSSC_OUT, cSSC_BAUD, "QPL0", 13]
serin cSSC_IN, cSSC_BAUD, 200000, TO_GPWAIT, [GPStatSeq, GPStatFromStep, GPStatToStep, GPStatTime]
The wait is .1 seconds which should be large enough. If you still have problems, try maybe 500000 (.25 seconds?)
I did not try with XBee plugged in or the like, but it looks like the version I have from you, was correct in it told the controller to disable and it disabled the timer, so the serout to start the command should go out fine… If you still have problems, you may want to hook up the logic analyzer and verify what it is going in and out of the SSC-32.
Thanks for your fast reply Kurt! If I get time for it today I’ll try to increase the timeout when reading the SSC ver. I’m still puzzled why the GP wouldn’t play when hard coding the GPEnable=1.
I’ll let you know when I’ve done some more work on this.
But the sequences won’t play. Immediately after commanding a sequence the next message I get on the DIY LCD is “Completed”. I did try to increase the timeout like you suggested but no difference. Looks like I need to do some more thorough debugging with the analyzer then… I have a feeling that the SSC don’t get the “start sequence” command correctly.
, where did you post it? I do like your ARC-32 version, especially the “extra” stuff with the servo offset feature, did you merge that to?
It’s getting messy with all the different code versions, I wish there was a better system for organizing the different versions on the forum. Maybe a thread just for code updates or something? Not spread all over many different threads.
