DIY Remote Control XBee controller for Robotics

WARNING: The hserial system has changed with the latest release of studio 2.0.0.0, here is a link to the release notes. Nathan updated the notes last night: forums.basicmicro.net/news-f481/ … t9437.html

With these changes none of the current XBEE projects will build. I did a quick update to the code and did a quick run test both on the Arc32 version of the phoenix as well as the BAP28 version (chr-3). I also verified that the transmitter would compile, but I did not test it…

Kurt

Warning: Check to see what debug levels that are set in each file. If in the phoenix code I have some debug options turned on the inputs will be limited (as to make it easier to trace what is happening and to make this work the same in my C code…) Also verify which input options are enabled. For Arc32 make sure the RC input mode is disabled.
DIY XBEE - Packet mode.zip (273 KB)

Kurt
Thank you for the code update
Phil

Kurt,
When compling the DIY Transmitter with the DEBUG on i get C:\Program Files\BasicMicro\Basic Micro Studio\bin\ld.exe : region text is full (d:\diy xbee - packet mode_sep_22_10\xbee projects\diy transmitter.bin section .text) error. I made sure it was the only one selected. compiles fine if i select any of the others.

As when CURRENT DL: is selected it displays the same as the CRRENT MY: Switched out xbee’s and the DIY(only) see’s that module as MY 00
I restored all my modules back to defaults and upgraded them to 10E8

I’m still having issues :blush: I’m taking it all apart and checking all my connections. I tested my XBEE’s and can communicate with them wirelessly using my ARC32. I’ll give all a try again

Thank
Phil

Hi Phil,

Actually in this case I was thinking of doing it on the robot side. With the Arc32 you should have lots of space. That way we can see if it is receiving anything and talking properly to it’s processor. If it looks like it is returning proper information for My/SN… than maybe try the VB application and see if it can talk to the robot. This way we can start to localize down which side is not working for you. I am pretty sure your transmitter is talking fine with it’s xbee as you were able to do the query to see what other xbees that are out there.

Kurt

Gave the DIY and the VB APP a run I got the same on both and entering T7 in the terminal window dosent do anything :blush:

Hi did you hit the ENTER key on your keyboard after typing in T7? Normally the command will echo something back. For example on my machine (Not sure if C or basic on my phoenix right now…

[code]Phoenix-Arc32 keyboard monitor
D ]] - Dump EEPROM memory
O - Enter Servo Offset mode
S - Download sequence(s) - VB call only
T ] - Set or show debug Trace level
V - View Sequence
: t7

Current Debug Level: 7(7)
[/code]
Also did you have a chance to add in the debug code I mentioned above to see if your robot is talking properly to it’s XBEE?

That was adding something like:

#ifdef DEBUG_XBEE gosub APISetXBeeHexVal"D","L", wNewDL] hserout "MY: ", hex wNewDL] gosub APISetXBeeHexVal"D","L", wNewDL] gosub APIGetXBeeStringVal"N","I", @_bNI, 20], _cbRead ; gosub APIGetXBeeHexVal"S","L",0x0], _lSNL ; get the serial low, don't enter or leave gosub APIGetXBeeHexVal"S","H",0x2], _lSNH ; get the serial high, hserout "DL: ", hex wNewDL, "X._NI: ", hex _lSNH, " ", hex _lSNL, "(", str _bNI\21\13,")", dec _cbRead, 13] #endif
As I mentioned I would add something like this to the end of the InitXbee function in (phoenix_control_diy-xbee.bas). Some of the variables may not be defined there. You could probably start off by just doing the My and DL and see if that looks correct.

Kurt

I did press enter after the T7 and no respone. I added #ifdef DEBUG_XBEE gosub APISetXBeeHexVal"D","L", wNewDL] hserout "MY: ", hex wNewDL] #endif to the end of the InitXbee function in (phoenix_control_diy-xbee.bas). no response
I tried it at “Enter: Init Controller” and it displayed “MY: 0”

Hi Phil,

I would like to step back a second and understand where you are so I can better help.

Which version of the Basic Miccro Studio IDE are you using?

Make sure in the config file that USEXBEE con 1 is set. You may want to make the USEPS2 to be commented out. Also make sure the USERC if defined is commented out.

In the …-xbee.bas the debug statements are defined: I have

;[DEBUG] DEBUG_XBEE con 1 DEBUG_VERBOSE con 1 DEBUG_ENTERLEAVE con 1

Ok you say if you put the hserout at the end of the function (before the return), you are not seeing anything, but if you put it at the start you are. This could be a sign that the program is crashing or hanging, which would also explain why the debug terminal did not show anything… In cases like this, I would do the following:

  1. Go to the main file (phoenix_v21.bas) in the init code, like right after it set Eyes = 0
    and add:
    wDebugLevel = 0xffff

That should default to all debug messages being output…

  1. Add enter/leave messages to waithser… like:

[code]WaitHSerout2Complete:
#ifdef DEBUG_ENTERLEAVE
hserout “Enter:WaitHSerout2Complete”, 13]
#endif
nop ; transisition to assembly language.
_WTC_LOOP:
mov.b @_HSEROUT2START,r0l
mov.b @_HSEROUT2END,r0h
cmp.b r0l,r0h
bne _WTC_LOOP:8

;hserstat 5, WaitTransmitComplete				; wait for all output to go out...	

#ifdef DEBUG_ENTERLEAVE
hserout “Leave: WaitHSerout2Complete”, 13]
#endif
return[/code]

  1. I would then go into the init xbee function, and add some more debug hserouts to see where it may or may not get to. Like put one inside the start of the code that conditionally compiles with the RTS line to make sure that code is not included.

After that we can try to see where you are…
Kurt

Hi Kurt,
Im using Basic Micro tudio 2.0.0.0
After following all your instructions, the speaker stopped chimming, the terminal displayed so much data i wasn’t able to read it.
and the XBEE modules really started to blink.I back tracked and commented out all the debug stuff. Now all seems to be working.
once i select the arc32 board the XBEE’s start to blink real fast. selecting “0” the speaker chimes and the servo’s move.
I checked the Phoenix-Arc32 keyboard monitor on the terminal and selecting T7 returns “Current Debug Level: 7(7)”

;-------------------------------------------------------------------- ;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 ;--------------------------------------------------------------------
Once I commented out USEPS2 the speaker started working as you mentioned. After commenting out USERC the othe things
i tryed seemed to work.

Could this be due to i dont have a PS2 or RC module installed?

Now to enjoy a cold grog
Thank you for your patience

Phil

Good to hear that things are starting to work! :smiley:

My guess is the RC stuff was getting in the way. Actually the code was not completed or tested yet :blush: The PS2 stuff may get in the way of some stuff, but for the most part it will simply just try to toggle a few IO ports and see it is not getting anything returning. The code was properly set up such that if it is not making contact with PS2 to keep trying the XBEE.

Sorry about that…

Kurt

Kurt,

Theres’ nothing to be sorry about. :laughing: This has been a very good learning experience for me

I thank you for the help

Phil

Thanks,

Warning: If you downloaded the recent package you should verify what input methods are enabled and also check to see what debug options that are set. For example in the Bap28 phoenix code the file up there probably had some debug either pin or body calcs enabled in the main source file. This very much limited the valid inputs as to make it easier to verify things on multiple platforms. But it very much restricted usage, like rotation while in walking mode did not work… To fix simply comment out the debug config statements at the start of the file. Those like:

;DEBUG_MAIN con 1 ;DEBUG_ROT con 1 ;DEBUG_PINCALCS con 1 'DEBUG_BODYCALCS con 1 'DEBUG_GAITS con 1
In the Arc32 version make sure that the RC input mode is not enabled and only enable the PS2 and/or XBEE. The code can handle both, but if you only have one only enable one… This is in the CFG file. Mine currently looks like:

;-------------------------------------------------------------------- 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
Soon I will test the RC.

Kurt

I had to keep mine as below. else the speaker kept chimeing

;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

Should I see any difference if using digital servos? I mainly have HS-5645MG

My guess is that you have no sound being generated at init time and the IO pin for the speaker is left as input and floating which may be the issue… Try adding something like the low cSound in the init section of the main source file. I put mine right after the part where it inits the LED values…:

;Turning off all the leds LedA = 0 LedB = 0 LedC = 0 Eyes = 0 low cSound ; make sure our sound pin is initialized as an output so we won't get buzzing...
Kurt

Added “low cSound” but it still did the same

Just to make sure, the speaker - has the radio shack part number 273-092 on the back of it. You have a red wire which you plugged into the signal for IO pin 19 (inner row of pins) and the black pin is connected to ground (outer most row of pins). I did this today to a second Arc32 that I use for testing and I am getting the appropriate sounds… If everything else is working you can always remove, this is just for making it easy to know something is happening…

Kurt

Kurt,
Yes the spearker is 273-092 and I have the red lead to P19 and Black to ground. If i uncomment USEPS2 the XBee’s dont communicate also

Hi Kurte…

Well I went through the process of the servo offsets(O), got done with that, and I had already hooked up a speaker as well as the ps/2 controller, unfortunately the ps/2 controller stopped responding just before I went to use it(red light on the ps/2 controller started flashing), and just the green light on the ps/2 module is on solid). So I unhooked the ps/2 setup and just applied power to the ps/2 module and all I get is a solid green light, no flashing red light at all now. Any ideas??

Hi Phil,
Not sure on the speaker, maybe try changing to another IO pin. Just need to move plus change the define in the CFG file. Note: make sure to move to IO pin that has an actual backing pin as marked as Standard IO capable marked in the spec. IE pins 8-15 will not work nor 24-27

Hi Charley,
Nope, sounds to me like the PS2 may have gone south. I had one do that recently as well, mine was different, I could never get the two to sync, even if I only applied power. I ordered a replacement which I received last week and it is working again. The only thing I would make sure of is to make sure where you plug into is +5v and not one of the VS terminals. I have found that they don’t work on higher voltages. Side note, recently I was reading that some controllers will not work at +5v either. That the actual PS2 game console runs at something like 3.4V. There is more information up on the Curious Inventor: store.curiousinventor.com/guides/PS2

Kurt

I found that the ps2 module is toast, everything else is fine, even doubled checked the voltages… Guess it’s off to the store to get a replacement…