Yep that would be good. Also maybe send/post me a zip file with the sources you are using so I can verify we are using more or less the same stuff. I can not debug it on a T-Hex but can do on the CHR-3… The interesting part is trying to figure out which side (T-hex or Transmitter) is causing the delay… For example is either/both sides calling ClearInputBuffer. Maybe put a beep in this function on both sides and see if this happens. If it is than being called, backtrack to the places it is called…
On the DIY remote side, you might try going into the function:CheckAndTransmitDataPacket
In here look for the code:elseif (_bAPIPacket(bDataOffset + 0) = XBEE_RECV_DISP_VAL )
In here maybe at the end put in a goto back to the top of the function to see if there are more messages to process… Something like:
elseif (_bAPIPacket(bDataOffset + 0) = XBEE_RECV_DISP_VAL )
; We will handle word values here
if (_bAPIRecvRet = 2) then
Gosub DisplayRemoteValue(_bAPIPacket(bDataOffset+XBEE_API_PH_SIZE) << 8) + _bAPIPacket(bDataOffset+XBEE_API_PH_SIZE+1)]
endif
goto CheckAndTransmitDataPacket
For good measure you may want to do the same for the display string and play sound…
If still delaying you might comment out the gosub DisplayRemoteValue… If it works we know there is an issue there…
I will continue to look on this end!
Sounds great and fun. Good luck with this!
Kurt
EDIT - Looking at the display value, I don’t like that I am only accepting a byte value in it, when the place that uses it passes a word and it passes a word to the next function. Probably not the issue, but you may want to change the function to:
[code];==============================================================================
; [DisplayRemoteValue (num)]
;
; This function takes care of displaying a number sent to us
; rom the remote robot. For now hard coded to a specific location on line 2…
;
; This function will also switch to the appropriate display mode if necessary.
;==============================================================================
wVal var word
DisplayRemoteValue[wVal]
; Make sure we are in the right mode to display the data
if TransMode <> TMODE_DATA then
; BUGBUG: Should put this into a change mode function…
gosub ClearLCDDisplay
bTDataLast = 0xff ; make sure we will display something when it changes.
TransMode = TMODE_DATA
endif
; now display the value - For now one or the other.
gosub DoLCDDisplay[13, 2, 0, wVal]
return[/code]
Thanks for looking into this. I did some more testing yesterday and earlier today, I’ve not tested the suggestions you’ve just posted. I’ll try it out later. What I found was the same I did for the ARC-32. After commenting out the XBeeOutputVal sub the bug didn’t occur.
The confusing part is that the “halt 0,5 sec error” is very random. The bug is most visible when doing continuous body rotations (move joystick in a little circle all the time and place the robot on a stand for saving energy). Sometime the bug occur just after some seconds and sometimes it can take up to 5 minutes…
I’ve attached the transmitter and robot code.
I’ve added the 0,1 resolution for body rotations and some more stuff in the control file. The LiPoSafety part can be turned off by commenting out the LiPoSafetyON const in the cfg file. Because of many different changes in the control file I renamed it (XP at the end), I’ve not tested this code in PS2 mode.
BTW: I do get some strange letters on the LCD in the Current MY window, I’ve not figured why. I can post a picture if you want. Beside that every thing seem to work very fine. T_Hex_4DOF_control_diy-xbee_XtraPot.zip (52.7 KB) DIY Transmitter_XP.zip (47.8 KB)
Hi Zenta, I hacked up your transmitter. Actually I ifdefed your extra controls. You can turn the extras on or off with the define USE_XPOTS in the file XBEE_TASERIAL_DEFINES.bas. There are some issues with your left joystick Up/down. I think you have code in to use offsets, but I think the old code is active as well. I fixed an issue (for without using the extra controls and displaying).
I added some code to my CHR-3 to display a value every N times through like you had and I don’t see any delays…
If you get a chance you might try this new files out. I think I left the new controls disabled.
If you still get a delay, you might go into the T-Hex file and in the function:
wXbeeVal var word
XBeeOutputVal[wXbeeVal]:
gosub SendXBeePacket[_wTransmitterDL, XBEE_RECV_DISP_VAL, 2, @wXbeeVal]
return
Maybe add a call to XBeeResetPacketTimeout before the return…
Quick update - I missed putting in 1 ifdef for the number of different visual pages…
While I was at it, I finally updated the select My page to not display garbage. I converted from using serout to the LCD to using the TASerout code that is used elsewhere. No big deal, but…
I did test the code (before your latest update) and also added the GOSUB XBeeResetPacketTimeout ; sets _lTimerLastPacket code you mentioned. But I still got the bug though.
I’ll try out your last update today, so I’ll let you know.
I’ve just done a little test with your last DIY update. I’m sorry to say that the problem got even worse. After a little time the communication stops completely, only solution is a reset.
FYI, I did also commented out the call to the XBeeOutputVal in T-Hex code again. The result got just a little better but still the 0,5 sec halt. So there must be something in the XBee code. I’m puzzled that you can’t replicate the bug though. Maybe I should try the Phoenix to, I’m pretty sure I’ll get the bug there also though.
Did you try putting the call in to the XBeeResetPacketTimeout? Although if you are still getting a pause with the call to XBeeOutputval commented out then that is probably not it…
Maybe I should try and go back to Bap28 on CHR-3 instead of Arc32…
Kurt
P.S. - It would help to know If there are any actions that you find that consistently causes the problem. For example yesterday I had my hex going in circles for a little while to see if that would do it…
Like I said before, I find doing continuous body rotations to be the best way to spot it. I’ve not seen the bug much when walking (not that I’ve tested the walking part very much though).
So far I have figured that we are getting some form of timeout. Not sure 100% of the case, but I think it helps to shorten the timeouts on the robot side. You might try something like:
CXBEEPACKETTIMEOUTMS con 150 ; how long to wait for packet after we send request
CXBEEFORCEREQMS con 300 ; if nothing in 1 second force a request...
I think this will minimize any effect on the issue. If you get a chance you may want to try it out.
I thought I would try a different tactic here. The current code waits for the transmitter to say it has new data before it asks for it. I thought I would try the other tactic if once the Robot has data, it asks for the next set of data from the transmitter without waiting for the transmitter to say it is different… It saves both on the logic as well as waiting for a message to be sent and received…
I tried it on my Arc32-phoenix with SSC-32 version and I think it works good. I also hacked up your T-Hex version that you posted. I only changed one file but uploaded a complete zip file…
Hopefully you will get a little time to try it to see if it works better for you.
That sounds like a really good idea!
I do hope to test it out one time.
Lately our baby has decided to keep us/me occupied in the evenings (normally the time when I can do some robot stuff ).
Luckily our baby gave me some free time today… I’ve been testing your latest update for about an hour now. This code seem to work much better! I managed to observe the bug two times at first . After that I changed the timeout values you mentioned. That seem to help alot. Then I made a simple function to toogle the send LiPo value using the #8 button on the DIY remote. At the same time i changed the timeout values back to your default (500 and 1000). The fun part and a bit confusing is that I’ve not been able to spot the bug anymore.
So, at the moment the code seem to work very fine!
I’ll have to add some functions I forgot in the transmitter code, my left up/down joystick is modified to be spring centered so that need calibration too.
Next step is to update the A-Pod code. The phoenix code should be no problem, thanks to all the #ifdef’s
Archer would require some work too.
I’m thinking, since we are using the API mode, is it possible to control two robots at ones?
Anyway, thanks for your help Kurt! Highly appreciated.
Yeah, I should now that by now since this is our 3. baby. But somehow I keep forgetting how it was with my previous kids. If I recall, I didn’t begin with more serious hobby robotics until our 2. son was about a year old. So I guess your correct, little time for robotics in the near future…
It’s always good to know you are not alone with a bug…
