As for the difference if debug is on??? As you deduced the only difference would be timing. So I would also try adding a slight delay. Looks like I need to generate a sequence on my hex to try it out.
As for having to hit “'0” again that makes sense. The receiver probably timed out as it heard nothing from the remote while the sequence was going on or it could be on the bot side as it timer would also say that the last valid message was at time X… . I could probably do a couple of different things. Update the timer on the bot such it does not think there is a time out. Or Could change the code like I mentioned I think in a different thread, to maybe have this code not hang around until the sequence is done, but instead return to the main loop which again checks for input, if squence is still in process, then check to see if it completed and then reset. The upside of this is the remote is being querried. Also it gives you maybe the option that if the sequence is running, pressing a key can cancel it…
I’ve attached the phoenix_V21k.bas and the phoenix_control_diy_XBee.bas files I’m using.
2. EDIT: Look for the BodyRotX1, Y1 and Z1. And the TotalYbal1, Xbal1 and Zbal1
Its rather easy to make a short sequence just for testing, you could just lift and lower a foot or something. (I mean the robot must lift the foot, not you… )
Maybe just sending some of the statsdata to the DIY remote? And update the timer, as you suggested.
When I started looking to your code, I thought at first that you had forgot the 13 cr. But then I saw you had placed into the string (Oncestr), very smart. I’ve learned so much by studying your code Kurt!
As you know I’m working with adding two more potmeters to the DIY remote.
The LCD are displaying the potmeter values in the “combined display with line” ok.
But in this part of the code I want to add the potmeters too:
if TransMode = TMODE_NORMAL then
if index > 5 then
gosub DoLCDDisplay[8, 1, keypress, 0] ; Changed from 11 -> 8
else
gosub DoLCDDisplay[abLCDUpdX(index), abLCDUpdY(index), 0, bPacket(index+2)]
endif
else
Since the Index value only goes from 0-7 I find it hard to show all 9 values(keypress included).
Is it possible to do two DoLCDDisplay in a row or does that take to much time? I’m asking since you are using the “gosub CheckAndTransmitDataPacket” very often.
I don’t think that will be problem of adding the display of a couple more numbers…
On my end I merged in your changes from the previous post. The only difference left in my file is that I fixed the typo in one of the messages.
Also for the timeout issue, I will try a minimalist fix first. That is if I receive a indicator that there is a new message available, reset the timer…
;-----------------------------------------------------------------------------
; [XBEE_TRANS_NEW]
;-----------------------------------------------------------------------------
elseif (_bPacketHeader(0) = XBEE_TRANS_NEW) and (_bPacketHeader(1) = 0) and (_bPacketHeader(2) = 0) and (_bPacketHeader(3) = 0)
; The remote has told us it has new data available for us, so we should now ask for it!
#ifdef DEBUG_OUT
serout s_out, i9600, "New data Packet received ", 13]
#endif
_fNewPacketAvail = 1;
GOSUB GetCurrentTime], _lTimerLastPacket ; again reset timeout
This way only this function still needs to know about timeout. If this does not work, I may need to introduce a function in a taser… to say reset timeouts and call it from phoenix_control…
Keep getting distracted from doing sequence. Keep trying to find ways to do it without having to change the wiring… Plus limited time on, plus Dirt 2…
Ok, I hacked in 1 sequence (without changing my comm port on my SSC-32, but it would probably have been a lot easier to do it the normal way. Converted EEP file to a basic program that did the EEW commands to the SSC-32… So now I know my test is working for a defined or undefined sequence. Also figured out why debug makes a difference. Again timing… The problem is without the debug, the XBEE is still sending the “Starting Sequence” message back to the remote, so SSC-32 message probably gets corrupted. I have done a two step fix for this. The first stop probably is all that is really needed.
In phoenix_control_diy-xbee.bas file when we start the sequence, I added a call to wait until the HSERIAL output queue is empty…
gosub XBeeOutputString@_GPSEQSTART] ; Tell user sequence started.
#ifdef XBEEONHSERIAL
gosub WaitHseroutComplete ; the communications interrupts may cause problems.
#endif
fGPSequenceRun = 1 ; remember that ran one...
GPStart = 1
It appeared to work with just this fix, but now I have to wait for my batteries to recharge to test more…
In the mean time I added some more bullet proof stuff to phoenix_v21k.bas to Toggle the CTS line to the XBEE so we should not get any communications from the XBEE to the BAP until the sequence completes. This may cause me to need to change the timeout code a bit or add a slight pause to give the XBEE a little time to download a byte or two before I get back into the input function… I will know more after the battery recharges…
[code]GPPlayer:
;Start sequence
IF (GPStart=1) THEN #ifdef cXBEE_RTS
gosub XbeeRTSAllowInput[0] #endif
… #ifdef cXBEE_RTS
gosub XbeeRTSAllowInput[1] ; Allow XBEE to go again #endif
ENDIF
I’ve tested your latest code and the sequences played ok now (without need for main debug)!
But, the beeping while no joystick movement are back again…
Yep, it is probably all about timing there. Will take a look, but hopefully this should not hold you up. Did you pick up the other changes I made in the zip file. I did add code to hopefully reset timeouts, but will need to debug.
Currently in process of hacking your excel to talk directly through BAP to SSC. Have most of the code in place, but now just need to send the connect packet, followed by the SSC_MODE message.
Sometimes I get a bit confused in the different Basic dialects. But should hopefully have it talk later today. Then will probably need to hack a little more on the SSC mode that when it is sending/receiving stuff from SSC to raise/lower the RTS line to make sure that the communications don’t get tromped by the interrupt. May also add some response when I enter this mode that returns the SSC version string… So then the basic at the PC can know the message was handled… Then maybe a little more handshaking with my VB app and then see if I can get SEQ to talk. So far it can see the version string, but fails on the EEPROM test…
I noticed that you did some changes to the “xbee_taserial_support.bas” file too. I think the beeping timeout was caused by the changes in that file. Because I got the same result using the TestXBee project.
You’re wanting a Basic program to respond to an SEQ version request (sounds familiar)? And then also respond to an EEPROM test? That sounds interesting! What do you plan to do with them?
I am trying to make a mode work within our XBEE version of the DIY/phoenix code that goes transparently through the XBEE-BAP to the SSC-32 and back. It would be nice to have our phoenix code running and decide I would like to test/change some of the sequences. So I go into MY VB app to connect or through Zentas excel to connect to the SSC-32. There I believe it will send on SSC-32 commands to move the legs. When we are done, either changes can be made to the excel or we could do the standard export and then run SEQ which can hopefully create the sequences and write it to the EEProm, where as we can then exit that mode and execute the sequences from VB or from the DIY remote. All without ever having to change wires or progams… At least that is what I hope for…
Ah yes! “pass through mode” I never got back to it after I got off of vacation. I think it would be very useful to have. The EEPROM is a new addition. While I’m not doing much with EEPROM now, I can see the usefulness there as well!
Me screwed up! When I converted some of the reset timer stuff…
[code]_RXP_CHECKFORHEADER_TO:
; Only send when we know the transmitter is ready. Also if we are in the New data only mode don't ask for data unless we have been told there
; is new data. We relax this a little and be sure to ask for data every so often as to make sure the remote is still working...
;
if fTransReadyRecvd then
GOSUB GetCurrentTime], _lCurrentTimeT
[/code]
If you look in the taserial… file Look for the label above and change to the last line here instead of resetting the timeout… Still get a beep at the end of running the sequence, simple fix is in the function when it sees the Activate message and we are already active, don’t beep… Better fix may be the more thourough update check to see if there are messages… Will look at this later.
I will update the zip file later, but doing some more testing of other stuff.
Ok I will update the zip file with the more updated stuff. This includes some of the work for having the PC talk to the SSC through the XBEES/BAP. My hacked up version of your XLS file now allows me to specify a MY/DL. Note: these need work as I assume the value is HEX but you can’t enter a real hex value. Currently if I talk to my HEX it’s MY is 0x31. So I enter 31 in this field which goes directly the the ATDL command. ATDL 31. The more interesting case is the MY field. I again set this directly from the value (ATMY xx), but then I need to pass this to the other side to tell them who to talk to. So I end up doing something like:
Val = (wMy\10)*16 +(wMy rem 10)
I added a new checkbox (Bap Transparent), that when checked and you do the Connect it will run a bunch of code to try to initialize the XBEE + send commands to robot to say Run SSC mode, which if it works the robot will make a certain sound. then you should able able to click on PEP->SSC to have it download stuff to your robot… I added some stuff to turn off the HSERIAL when it is trying to pass on the commands to the SSC as to not have it corrupted.
Need to test more but all of the sequences are for INLINE hex (phoenix) so I need some sequences for the CHR… Also would like to make this initial handshake send something back so the XLS knows it really did connect… Note: the disconnect sends the $$ which tells the BAP to exit SSC mode and it again should make a different sound.
Also update the VB test program to be that from the Vb express 2010 beta.
Sounds great Kurt! I’m looking forward to try this one time. Beeing able to switch between these two modes sounds awesome!
I tested your latest code yesterday and it seemed to work very well! 8)
But I noticed that the max/min values on the joystick values was a bit off again, so I tried doing the joystick calibration. The joystick calibration went ok with message “Updated”. Then the center-calibration is done and I notice that the max/min values are still a bit off.? (FYI, I did only move the joysticks up/down, right/left from the centered position, not to the 4 outher corners)
Another thing, when I restarted the DIY remote it doesn’t seem to restore the calibrated values.
I noticed this code in the GetSavedJoystickRanges sub :
; if we fail for some reason just default to our defaults...
AToDMins = 392, 416, 361, 426, 0, 0
AToDRanges = 636-392+1, 630-416+1, 598-361+1, 638-426+1, 1023-0+1, 1023-0+1
I’m not sure if it is these values that get restored or what.
I’ll see if I can do some debugging to see the actual AD readings from the joysticks.
No idea on the offsets. That would happen if the saved values and restore values don’t match. Ie there is a byte that says how many bytes were saved and a checksum that is computed and stored. Have you started adding the two extra controls? You may want to through in some debug messages around the save/restore (SaveJoystickRanges/GetSavedJoystickRanges) and see if they are called and see if the values are not considered valid…
Hi again. I forgot to ask how much of the range you are not getting… One thing I considered doing earlier was in CalibrateJoySticks use a fudge factor to make it think the range is slightly smaller than what you discovered, such that when we did the actual reads, we would probably slightly extend beyond 0 and 255, but also have it rely on the code that will constrain the output to the valid range. I also thought about maybe folding the functionality of the function: Calibrate into the CalibrateJoySticks function and maybe adjust the calculations slightly.
That is have the CalibrateJoysticks function have you move the joysticks like now both Min’s and Max’s and leave the joysticks at their zero points. From this maybe adjust the formulas to calculate the output to take this into effect. I am not sure if I am explaining this well, but maybe an example would help. Suppose for one of these joystick values you find the minimum to be 392 and the maximum to be 636, as such you have a delta of lets say 245. If it joystick was exact you would expect the center point to be 514, but suppose you run through a few samples and find the center to be 510. So if you use the straight formula to compute the outputs:
(v-510)*256/245, if you compute for V=636 ->131 and V=392->-123 So we clamp off 132 to 127 but we don’t get the full minus range.
Couple of solutions. We see in the negative range we have 392->510 or 118 values and in the positive 510->636 or 126 values.
a) Act line our range is 2 times the minimum. or 392-618 (diff of 237) so
(v-510)*256/237 so V=636->136 and V=392->-127, so clamping off top we get the full range but we do peg out the top side. (Note, we would need to adjust the bottom if our measured center was above middle (like 518).
b) You adjust the formula depending on if you are above or below the range in that direction. So in this case
Positive something like (v-510)*128/126 so 636->128
Likewise negative (v-510)*128/118 so 392-> -128
So the question is A) is really easy to implement, B) is a little harder but not terrible. What do you think? Should I try this or do you want to take a crack at this?
Hi Again, OK I hacked on the transmitter code and hopefully have it get the full range better. I did it more the way of b) from the previous post. Also fixed a minor bug in the choose robot from list that moving the joystick up works better… I also slightly changed the compute checksums in the read/write joystick offset functions as to make what is currently stored invalid as what I now store in the min8 and the max8 (as in everywhere we use the values we multiply by 8 as we have the sum of the last 8 adins…)
If you get a chance try it out and make sure I did not screw anything else up
Edit: I forgot to mention, I get better results when in the calibrate screens, if you move the joysticks straight up and down and straight left and right and not move them into the coroners as this will get you closer to 0-255 when you move in one direction only and we will clamp the values in range if you go diagnally…
Hi Kurt,
Thanks for your explanation about how you’ve done joystick calculations!
I’ve been a bit busy lately but I got some minuttes for testing your latest code.
Much better Kurt! The calibration part worked perfect. 8)
I believe I found the reason for why the stored joystick ranges didn’t work. If you take a look at your GetSavedJoystickRanges sub:
[code]GetSavedJoystickRanges:
ReadDm JoystickRangesDMStart, [cbXBee, bXBeeCS]
#ifdef DEBUG
serout s_out, i9600, "Get Saved Joystick ", dec cbXBee, " ", dec bXBeeCS, 13] #endif
if cbXBee = 24 then
ReadDm JoystickRangesDMStart+2, [str AtoDMinT8\12, str AtoDMaxT8\12]
for i = 0 to cbXBee/2
bXBeeCS = bXBeeCS - (AtoDMinT8(i).lowbyte + AtoDMinT8(i).highbyte + AtoDMaxT8(i).lowbyte + AtoDMaxT8(i).highbyte)
next
; If I did the right if valid the cs should be zero
if bXBeeCS = 1 then ; changed checksum to bias by 1 to not match old data...
return;
endif
endif
; if we fail for some reason just default to our defaults...
AtoDMinT8 = 392*8, 416*8, 361*8, 426*8, 0, 0
AtoDMaxT8 = 636*8, 630*8, 598*8, 638*8, 1023*8, 1023*8
return[/code]
Did you see it? …
The default values are the values that are restored all time. So I simply remarked them and the function worked fine. I guess there should be an “else” command there.
Yeah, you told me that before. And I believe I said I did that too for a few posts ago.
I’ve done some testing with Phoenix and the DIY remote seem to work very well.
But there is a random bug in the Phoenix code somewhere. When I’ve played for maybe 5 minuttes (sometimes for shorter or much longer time) the movements gets very choppy, especially visible when doing body movement. I’m not sure if its the communication or the phoenix code, because I’ve noticed this bug for a long time. Also under normal RC control (before XBee), but not that visible as now.
I guess I’ve to do some debugging. And I’m not sure if you or Xan has noticed this bug. The hard part is that it is random.
Anyway, thanks for sharing you awesome work Kurt!
The DIY XBee remote code seem to be very close to perfect now.
)
Congrats on 
