This sounds like the good news! Well done, looking forward to test it out one day.
Ah! I hate that smell too. I did also lost two servos before christmas.
Oops! Did you made the CHR-3 walk with āmyā phoenix code and cfg? Iām so sorry Kurt , but I forgot to tell you that Iām not using the register offset on the SSC32. My code compensate for the offset with an offset value stored in the cfg file. That might be the reason for why your servos got overloaded. Iāve choosed not to use the SSC register offset mainly because its limited to only +/-100. That wouldnāt be a problem for Phoenix though, but for Felix and T-Hex Iām using much larger offset for some servos (up to around 3-400). I donāt know if the ARC-32 has any offset registry either? (Another reason for why the offset should be inside the code.?)
Iāve said this before. Since the ādiy transmitter xbee.basā file works fine on the DIY there must be something in the new project code that make the timeout happend.? The hardware seem to work very fine. Its just to bad you canāt replicate the bug. Iāve no idea what it isā¦
Hi Zenta, I tried making some changes to current version of the tranmitter code to make it closer to the old. That is it now checks to see if there is any avaliable input on hserial and if so it reads with a longer timeout. Also found some issues with checking some variable in a timeout that was more valid when using the taserial support. So could you try this version of the file and let me know if you get better results:
Iāve tested it, but still I canāt get any connection to Phoenix.
Do you have any tip if there are any variables/contants I can try other values for regarding the timeout?
Iāve also tried other XBee modules but still the same frustrating result. But I just canāt understand why it work with one code and not the other one though.
Thanks for trying helping me out here.
EDIT:
I changed the XBeeās PAN ID and Channel to other values but that didnāt do the magic either, just FYI.
If you run the test program, do you get any results that look like:
******** XBee Test Program ********
MY: 30
SH/L: 13A200 402C4240
Dest: 0 99
NI: Test Board
Ver: 1084
Ready: 99
Send DP:81FFFF00:
Send DP:81Ć¢ā¬ FFF00:
0000000000000000 127 127 128 38 255 255
New data Packet received
Send DP:80030300:
New data Packet received
Send DP:80040400:
Send DP:80050500:
Send DP:800606p0:
New data Packet received
Send DP:80070700:
00`0000000000000 128 127 128 38 255 255
New data Packet received
Send DP:80080800:
0000000000000000 127 127 128 38 255 255
New data Packet received
Send DP:80090900:
New data Packet received
Send DP:800A0A00:
New data Packet received
Send DP:800B0B00:
New data Packet received
Send DP:800C0C00:
Send DP:800D0D00:
Send DP:80pĆ¢ā¬Ā¦0E00:
New data Packet received
Send DP:800F0F00:
0000000000000000 128 127 128 38 255 255
New data Packet received
Send DP:80101000:
0000000000000000 127 127 128 38 255 255
i.e. does the test program show real packets coming over when move things around are the like?
You can try bumping up the timeouts in xbee_taserial_support.bas. Those are:
[code]#ifndef CXBEEPACKETTIMEOUTMS
CXBEEPACKETTIMEOUTMS con 250 ; how long to wait for packet after we send request #endif
#ifndef CXBEEFORCEREQMS
CXBEEFORCEREQMS con 1000 ; if nothing in 1 second force a requestā¦ #endif
#ifndef CXBEETIMEOUTRECVMS
CXBEETIMEOUTRECVMS con 2000 ; 2 seconds if we receive nothing #endif[/code]
Try doubling each of these and see if it helps. Need to rebuild the phoenix for this.
OK, so we are not receiving any valid packets back from the transmitter. Did you move any of the joysticks while the test was running? Let me look more to see what debug stuff to have you turn on.
Right now I am in the process of trying to fix my HEX. Not sure of the chicken and the egg here. I had the servo wires for the other two servos running under the hip servo. But you can see in this picture: It looks like the bottom of the motor more or less burned through the bottom of the case. The two wires under it as you can see are pretty charred as well. Next to see if those motors are OK or notā¦ FYI - The servo that fried was a JR-SPORT ST125MG that I picked up when I was a servo or two shortā¦ Hopefully my spare will work. Ordered 6 more 645s just in caseā¦
Kurt
Well I think I have my hex back in one piece and now back to the problem at hand.
I assume from your last trace that you changed the MY of your transmitter to 99.
I turned on some debug output in the transmitter program.
here is a partial trace from the run, need to hook up to serial input on Transmitterā¦ I have two USB to serial connectors hooked up on my machine, so for some runs I open two terminal tabs, split them horizontally and connect to both the transmitter and receiver programs and that way can see how they are responding (or not to each other).
The Recv messages are the 4 byte packet headers it receives. If you see a bunch of TP IN messages those are ones that are not understood. May need to later add Timeout messages where we are not receiving whole packet. It was not unusual to have some unknown gunk at the beginning. The code should then try to get rid of everything in the queue which usually then gets things rollingā¦
Another long shot, but to make sure the my is set properly by the transmitter code. That is maybe double check that if you have the two programs running, go to X-CTU with a third one and do the ATND and see what the MY values are actually set to.
Yes, of course I moved all joysticks and I believe I tried everything. I also tested it with the ādiy transmitter xbee.basā program and that worked very fine as always.
Doesnāt look very good. You said that two of your servos broke, was the other one also a JR-Sport?
Iāll try the debugging part this evening. I have a rather old PC on my workshop with two serial ports and I believe Iāve two serial cabels too. So Iām looking forward to try it out.
Iāve started doing some modifications on the ādiy transmitter xbee.basā for adding a potmeter. So far Iāve modified the AD reading and got the result displayed.
Here are some pictures of the custom part Iām going to use as a stick with potmeter on top:
Iāll have to make one more part for the other joystick.
Iām not sure where to guide the wires yet. Iāll post more info about that later.
Looks good, I put some more debug stuff in and moved some around.
The debug stuff may not print as well as for example in the send packet function I moved the send of the data up in front of the displaying the stuff on the debug terminal as to not slow the packet down by waiting for the 9600 baud serout. But the interrupts from HSERIAL will cause the debug stuff to be screwy. I also only output the 4 bytes of the header and not the whole packet, unless you turn on DEBUG_VERBOSE. Also added some more debug outs on the robot side to see if we are not actually receiving packets. Before I would only display info in the actual program and only if it though data had changed.
I tried changing my MY on the remote from 99 to 88 and it worked and I confirmed it with the USB xbeeā¦
Kurt
Edit: I think I may know what was wrong and put an updated file up here ā¦ XBEE_RTS was still defined in DIY Transmitter.bas So the code Probably saw that and went into the XBEE Init code which turned on Flow control. On my Transmitter I am using an APPBEE xbee holder which has true voltage shifter IC in there hooked up to the RTS line so while the input was floating it probably left it low. Where on yours with the Sparkfun adapter it is truely floatingā¦ So hopefully it will now work. If so you should probably comment out the DEBUG and DEBUG_OUT defines.
That did the magic! Well done Kurt!
The ATND fuction worked now, and I found Phoenix (not an unknown_xx).
I got contact with Phoenix. So it seem to be working better.
But there are some glitches and bugs in the communication (I commented out the debug defines). If I donāt move the joysticks the robots start beeping and after about 30 sec there are no contact. There are also some strange stuff comming up on the LCD display too. Iāve not got much time for testing but I feel there are some glitches in the general communications too (now and then).
To be honest, the old diy program that worked all the time seem to do a better job thoughā¦
The glitches with the LCD is that this version of TAserial does not appear to be as immune from timing glitches caused by HSERIAL. But the old one I donāt think could handle 115200, which is what we are using to talk to the SSC-32. What I have tried to do is to share all of the same code. Can always revert back to older version. Will have to figure out what the differences are for the 30 second stuff. Should be more or less the sameā¦
Hi Zenta,
I have not done much yet on this, except I did do a version using the old TASerout, which does appear to work better.
You can try it by using this version of the transmitter file. Maybe I will have to revist the cleaner version that is part of the support file versus this one which appears to have a better handling of the HSERIAL interrupt processingā¦
Kurt
P.S. - I think I now have 12 new 645 servos coming my way so I should not have any down time if another one blowsā¦ And it is a nice start toward other projects
Sounds promising! Iām a bit busy today but I hope to try it out this weekend.
Thanks again Kurt!
Thats great! Are you planning to replace some of the JR servos or building something new?
I did also got 5 XBeeās and 5 regulated boards today. Iām looking forward to try out your new code and hopefully soon start on mounting the XBeeās on all my robots too.
Iāll let you know when Iāve tested your latest code.
Sounds like fun with the XBEES. That is why I did the stuff to allow you to choose from a list as I kept forgetting which ID I gave to the Brat or the CHR or ā¦
Will debug more about the dropping. Right now I am playing with the run a GP sequence. there are bugs in my current uploaded code that on some of the calls to TASerout and TASerin are missing @s on some of the calls with the bufferā¦ But since I had no sequences I did not test much . While I was looking that the code and trying to debug some stuff Robot Dude had questions on I did try running some sequences that were not defined and I think I hung the SSC-32. So I modified the code for the XBEE that first checks to see if it thinks a sequence is defined (does a EER -<sequence Number*2>;2) and then does a read for the two bytes. If they are 0 or 0xff then error out. Also while I was doing it, I thought I would define text messages that display when you start the sequence and end the sequence and if there is an error. Just finished coding and compiling, to find out I ran out of program space if I have some debug stuff turned on. So maybe I need to cleanup some more, maybe get rid of some messages, ā¦ !
As for servos, I bought them to maybe build a phoenix over time. Still need another 6 servos and then the bracketsā¦
Iāve tested the latest ādiy transmitter.basā. At first try I didnāt get contact with Phoenix at all. Then I tried the old ādiy transmitter xbee.basā again. I got contact with Phoenix and I was able to control it, but when the joysticks wasnāt moved Phoenix started beeping againā¦? I concluded that the new āxbee_taserial_support.basā was the reason, so I replaced this file with the old one dated december 23. and compiled the phoenix code again.
After that, the Phoenix didnāt start beeping (timeout) due to no joystick movement.
Then I tried your latest ādiy transmitter.basā file and compiled the diy project again.
And the DIY remote worked perfect! 8) No timeout issue or glitching at all.
I also tested one of my new XBee modules with ATNI= T-Hex and MY=31. Did the (A) ATND on the DIY and it found the T-Hex module at first try. The DIY did also changed the DL to 31 correctly!
Iāve no idea why I needed to compile the phoenix code with the older "xbee_taserial_support.bas.? I guess you know the answer to that Kurt
Anyway, the DIY remote seem to work very fine!. Thanks Kurt.
Iāve some sequences stored on my SSC, so I can test it out for you.
Hi Zenta,
Sorry I am a little slow respondingā¦ Handsā¦
Note sure why you were having problems with TASERIAL stuff on phoenix. Here is my current stuff. I was able to talk ok with my chr-3. It also has the code that hopefully should run canned sequences properly. Mine just tells me that each of the sequences is not definedā¦
Iāve tested your latest code. Just for a very short period of time, Iāve very little time for robotics in the weekends (family stuff).
The DIY remote and robot communication seem to work fine.
But I didnāt manage to run a sequence. I hit the āFā button for entering sequence mode, then hit the ā1ā button for playing sequence 0 (is that correct?). The LCD display show āStart Seqenceā (a tiny typoā¦ ). Nothing happends and the display show āWalkingā again.
Iāll take a closer look into your code later to see if I can find it out why the sequence doesnāt play.
I know I should probalby try to define a sequence and download itā¦ Am playing with your excel SS to see if I can make it talk through the BAP to the SSC-32. Trying to convert from VB to the VBA using the Comm macros you were using. Trying to figure out for example when you read in the SSC-32 version. I think you just wait for the timeout to happen from the SSC-32 and assume all of the bytes.
As for 1 playing sequence 0, I think that is what Xan did before I XBeed itā¦ As for showing Walking, it is called copy and paste and not updating the message pointer. Look at the code:
[code]ControlInput: #ifdef DEBUG_ENTERLEAVE
serout s_out, i9600, āEnter: Control Inputā, 13] #endif
; Not sure the best place to test this, but if we ran a sequence and now
; it says it is not running, let the user know this.
if fGPSequenceRun and (GPStart = 0) then
fGPSequenceRun = 0 ; clear out the dataā¦
gosub XBeeOutputString@_GPSEQCOMPLETE]
endif
[/code]
You will notice that the output string in the code has the WAlk not complete message pointer.
So it thinks it completed. I assume you also picked up the updated phoenix_v21K file. If not you may want to look at where I was calling up the sequence, probably a couple @s missingā¦
As for the previous message. Yes I would like to build the phoenix, but was hoping Jim would release the version of the legs with the contact switches so I can play with thoseā¦
Iāve been trying to figure out why the sequence wonāt play. But something strange happend when I turned on the main debug. While the āmain debugā was turned on, the sequence played! And all the statsdata was streaming on to the terminal window. Then after the sequence was finished the servos got turned off or something. I had to hit the ā0ā button again for making it walk. Strangeā¦ When the main debug are turned off the sequence wonāt play again. I tried adding a little pause in the GPWait loop, but that didnāt help. Any idea?
Another thing: I guess you didnāt try the body rotation with your current code?.. The code I sent you was modified with 0,1 deg resolution for the bodyrotation. Youāve to modify some parts of the phoenix_V21K.bas code and the phoenix_control_diy.bas file. Or if you want, I can post the code again.
Did you made the CHR-3 walk with āmyā phoenix code and cfg? Iām so sorry Kurt 
, but I forgot to tell you that Iām not using the register offset on the SSC32. My code compensate for the offset with an offset value stored in the cfg file. That might be the reason for why your servos got overloaded. Iāve choosed not to use the SSC register offset mainly because its limited to only +/-100. That wouldnāt be a problem for Phoenix though, but for Felix and T-Hex Iām using much larger offset for some servos (up to around 3-400). I donāt know if the ARC-32 has any offset registry either? (Another reason for why the offset should be inside the code.?)
An expletive would be appropriate at this point:
Very appropriate indeed!
It looks like the bottom of the motor more or less burned through the bottom of the case. The two wires under it as you can see are pretty charred as well. Next to see if those motors are OK or notā¦ FYI - The servo that fried was a JR-SPORT ST125MG that I picked up when I was a servo or two shortā¦ Hopefully my spare will work. Ordered 6 more 645s just in caseā¦
I moved all joysticks and I believe I tried everything. I also tested it with the ādiy transmitter xbee.basā program and that worked very fine as always.
ā¦ XBEE_RTS was still defined in DIY Transmitter.bas So the code Probably saw that and went into the XBEE Init code which turned on Flow control. On my Transmitter I am using an APPBEE xbee holder which has true voltage shifter IC in there hooked up to the RTS line so while the input was floating it probably left it low. Where on yours with the Sparkfun adapter it is truely floatingā¦ So hopefully it will now work. If so you should probably comment out the DEBUG and DEBUG_OUT defines.