DIY Remote Control XBee controller for Robotics

[zenta]

Hi Kurt,

I’ve just done some small changes, all related to the eXtra Potmeter stuff.

Did also do a little modification to the DisplayRemoteValue sub:

[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]
#ifdef USE_XPOTS
; Make sure we are in the right mode to display the data
if TransMode = TMODE_DATA then ;Zenta: I don’t want to see the remote value unless we are in the TMODE_DATA
; now display the value - For now one or the other.
gosub DoLCDDisplay[13, 2, 0, wVal]
endif
#else
; 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]

#endif

return[/code]

Personally I preferred to only display the value when we are in the TMODE_DATA, (IMHO).

A 4 line LCD module would be great though!
diy transmitter.zip (48.3 KB)

[kurte]

Sounds good!

Thanks
Kurt

P.S - Yep a 4 line would be nice

[mam309]

@zenta

@kurte

I made the 4 wire Y cable, where one end was 4 female connections to plug into the keypad (the 4 wires with pullups). I wired one of the groups of 4 wires with male connections, such that I plugged in the wires coming from the BB2 and then the other set had a wire going to each of the four new switches. I then ran a common wire to the other lead of each of the 4 switches and this wire continued and was plugged into the P17 on the BAP.

Hi Kurt,
As you know I’ve decided to add the XBEE’s to the DIY too. First I want to add the four cmd switches. Since I’m not 100% sure how you’ve wired the new buttons I would like you to take a look at my little schematic here (quick and dirty hand written ). Does the schematics look correct?

Hi guys. I’m designing my own version of this controller with some different hardware. If your still looking for a way to gain some more switches, check this out. This is how I’m going to wire a 4x4 keypad and 16 switches. It requires only 8 I/O’s from the Micro. If you get a little creative this can be reduced to 6 I/O’s.

Note: each switch requires 1 diode. I used 1N4148’s.

[zenta]

@kurte

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…

Hi Kurt,

I did some testing yesterday on Archer and it looks like he got the 0,5 sec bug too. Is it easy to post all the changes you did on the control_xbee for the fix? Or can I use the same control_xbee file from the universal T-hex code. I guess your code from 24. December also has the little bug since the fix came after that.

[mam309]

Hay guys, I’ve been making a little head way with mine and thought I would share.

youtube.com/watch?v=E0kwG74CUYI

[robotical]

Hi,

about the last code revision, I’ve a question

i’m not sure where i can plug RTS wire
i’ve connected all like this but i don’t know if it’s true:

AX0=P16=RTS
AX1=P17=RowB

AX2=P18=LEFT SLIDER
AX3=P19=RIGHT SLIDER
P0=LEFT VERTICAL GIMBAL
P1=LEFT HORIZONTAL GIMBAL
P2=RIGHT VERTICAL GIMBAL
P3=RIGHT HORIZONTAL GIMBAL

P4=col0
P5=col1
P6=col2
P7=col3

P8=LCD

P10=row0
P11=row1
P12=row2
P13=row3

P14=XBIn
P15=XBOut

thanks

[kurte]

Note: Currently I run mine without the RTS wire, so I leave it undefined. Why? Because Zenta added more stuff to his and ran out of IO pins, so I leave it off, to make sure that it is OK enough for his remote.

Before I would use P16 on mine with a large caveat. That is I on my transmitter I am using an XBee conversion board by Selmaware (no longer making them), that did true voltage conversions between 3.3 and 5V, including the RTS line. I believe the parallax ones do as well, BUT the sparkfun one does not. That is why on robots that I use the sparkfun ones, I make sure to only plug the RTS line into P7 or P8 of the Bap28 as those pins have a lower output voltage… I have heard some that have plugged +5v directly into an XBee input and say it works fine, but normally I would not chance it.

Kurt

[robotical]

thanks.

convert parallel lcd to serial
i modified the sparkfun source code. Baud rate has been changed to work with the remote at 19200 baud. it run on 16f688

schematic at:
sparkfun.com/products/9395
I need to do some modification on the remote control code because display is shift

i hope post it tonight
i never saw run the remote before. To place all menu at the correct place, it is difficult.
At this time I’ve added :
pause 500
gosub TASEROUT[Display,i19200,@_CPrompt2,15]
in calibrateJoysticks function when error.

To allow compatibility: string len of TASEROUT must be changed and offset on the display because 71 is replace by 64+%10000000,etc.

64 is for second line
See code for further information;)

All is done, I test it. I’ve just little trouble with the display of positionning
[Sorry for my bad english]
serlcd2.5 modified.zip (7.6 KB)

[robotical]

here is the beta code of diy
there is a little problem to display joystick values in the 2 mode.
some garbage char appears…
i’ll post the last sourcecode saturday.

diy transmitter for serlcd2.5b.zip (45.9 KB)

[kurte]

Looks like you are making some good progress!. Often with garbage characters on the display it is due to HSERIAL interrupts happening while characters are being output to the display. That is where it is nice to use the RTS line as you can tell the XBee to not send you anything and you can put a call in to make sure the Hserial output queue is empty…

Kurt

[robotical]

display of different joy and slide value bug solved.

here is the final code.

DoLCDDisplay[bLCDX, bLCDY, bLCDChar, bLCDNum]

abLCDBuff = 254, %10000000+ bLCDX-1+ (bLCDY-1)*64		
if bLCDChar <> 0 then
	abLCDBuff(2) = bLCDChar
	cbLCDOut = 5
else
	; May later handle +- types of numbers
	abLCDBuff(2) = dec4 bLCDNum\4
	bLCDChar = 2
	while (bLCDChar < 7) and (abLCDBuff(bLCDChar) = "0")		; reuse the passed in char field as an index
		abLCDBuff(bLCDChar) = " " ; remove leading zeros
		bLCDChar = bLCDChar + 1
	wend
	cbLCDOut = 8
endif	

; now lets call our taserout function
gosub TASerout[Display, i19200, @abLCDBuff, cbLCDOut-2]


return

diy remote for sparkfun 2.5(rc).zip (45.9 KB)

[dialfonzo]

Sorry for posting here…

i want to know what you think. If i get one of those:
robotshop.ca/microcontroleur … usb-2.html

Would it be easy to make my own Transmitter ?
I plan to use xBee

Tanks

[kurte]

@DiaLFonZo

i want to know what you think. If i get one of those:
robotshop.ca/microcontroleur … usb-2.html

Would it be easy to make my own Transmitter ?

The answer is maybe, but It will be close on IO lines here.
This has 6 Analog pins and 14 digital only one UART which is used by USB…
6 Analog: Good for 2 joysticks plus 2 sliders (Good)

2 digital/UART for USB
9 pins for Keyboard plus 4 extra buttons. Could use external chip and maybe save - was somewhere in threads…
2-3 pins for XBee - probably need RTS here…
1 pin for LCD display
1? maybe for some speaker…

Now if you used one of these: nkcelectronics.com/seeeduino … mbled.html
or the like, there would be plenty of Uarts and IO pins you could do a lot.

Working with XBees may be fun on the the Arduino, especially if you need to use the software serial library, as you only receive characters when you are in the read statement, I don’t think they have any concept of the RTS line, so you either have to roll your own protocol to handle the communications or maybe a new software interface…

Kurt

[dialfonzo]

Tanks Kurte,

It’s the same as this one i guess
robotshop.ca/microcontroleur-seeeduino-mega-seeedstudio.html

With your experience, witch way should i go… lol

[kurte]

Yep looks like same one. Probably depends on shipping costs. NKCElectronics had it for $42.50 and robotshop.ca had it for $48.50… Personally I like the megas and have purchased the one I mentioned as well as the official Mega…

Kurt

[kurte]

Quick and Dirty minor update,

I was playing around with the C version of the phoenix code and testing out AtoD conversions and thought I would add in the code that checked the battery status and display the current voltage on the DIY remote control. But I have two batteries and thought it would be nice to display both voltages, but my old Display Value would only display one value. There is room to probably display 3 values, so did a quick and dirty version, with 3 new display values (0 goes in col 0, 1 goes to col 6, 2 goes to col 13).

I added support in the remote control code, I also did it to my C version as well as my combined Arc32 phoenix code (the one that works with or without the SSC-32…)…

Kurt
Diy Transmitter - back to zenta.zip (95.4 KB)

[robotical]

hello,
i’ve two ideas for the remote …interesting or not
First.

toggle display of second line with [enter] key to display date time voltage(Zenta) :

first line:  Left/right/key:    POSX   POSY 

second line: HH:MM V:xx.x
HH:MM dd/mm/yy
dd/mm/yy V:xx.x

i don’t know if a low power state mode exist on bap for remain time or rtc built in. a second battery (3V)+ pic can do the same. I’m looking on web after post.

possibility to switch on /off xbee+LCD to keep time. Date is a simple formula

Second.

a new extended feature:

a loader for configuration file of predifined functions for all type of projects
.
Editing sequences, etc
need to allocate some reserved place in EEPROM to store all

lenght of space occuped is constant

i’ve already added a part in the menu of remote [Loading .Bin] Loading by xbee

===============================
file header(vb6 declaration )
index as byte
botname or xbeeSerial as string
HexValueKeypadLink(00 to FF) as byte (sbyte for bap)
NumberOfCommand as byte
CommandArray() as integer ; low nibble is for
the time of one command
high nibble is for command

[kurte]

All ideas are interesting! Also that is the fun with the DIY control, each of us can decide what it is we want

For me, I am not that interested in Date/Time, but that is just me… The BAP does not have any RTC. You can always add one external to it and assuming you have some IO line(s) available can read one in.

There are times I really wish, I could display more information and am at times tempted to replace the LCD display with either one with 4 lines of text or something like the graphic one mentioned in this or a different thread. For example with the phoenix, It would be great to be able to display what mode we are in (Walking, rotation…), What is the current Gait, Is balance mode on, Voltages (both for robot and the remote)…

Part 2 - I earlier made the decision for my usage of the remote, that I wanted the remote to know nothing about the robot it was connected to. It simply sent it data and displayed or sounded data that the robot sent back to it. That made it easy to switch from robot to robot, you simply needed to change the destination address of the XBEE and you were off communicating with the other robot. Also it made it nice that in addition to the Remote control, you could (and I do) have something like a VB application on the PC that I can use to also control the robots and get the same messages… This works fine for me, but is this the only way to do this? No…

There are many ways to do this, which have both pluses and minuses… For example I have at times considered, adding an additional way to display messages, where I may define several different standard messages and store them in the remote control (Code space or EEPROM?). Then the robot could send a message that says display message N… There are pluses to this, which include, maybe reducing the code space on the robots (great if you are running out of room…), Smaller message imply less overhead… Also if you were doing this as part of a commercial product, you could have different language translations for these messages. Downside is, are there really very many common messages between my different robots (Hex, versus Biped, versus Rover…). I also use the messages for debugging, so would still want to keep the other method as well…

As for sequences. I personally prefer to have each of the robots themselves know their own sequences and through some command message sent from the remote to the robot have the robot do it… Also I do have pieces in place, that allow me to download sequences to the robots, which update the EEPROM (one version updates SSC-32 EEPROM, another updates EEPROM on Arc32, with my own code on the Arc32 that emulated running a sequence on the SSC-32). I don’t remember right now if I have the XBee doing this or not, but have meant to do this. This is one of the reasons I converted to Packet mode… But again this is how I have decide to make my robots work.

I could easily see how others may want the remote control to be in more in control of the robot. Could imagine for example having the remote talk to a robot that only has an SSC-32 with an XBee connected to it and having the remote be able to download and run sequences or maybe run it’s own sequences… There would be issues like packet mode will not work with just an SSC-32 so would need to switch to serial line replacement mode…

I am looking forward to see what all you come up with!

Kurt

[dialfonzo]

Hi,

I am looking to build my own Transmitter.
I will more than likely use a:
robotshop.ca/microcontroleur-seeeduino-mega-seeedstudio.html

I have made a little SWK drawing to have a look of it…

It’s based on my ginbal and my uOLED-128 display.

The 2 hole on top of ginball are for 2 rotating pot, and hole on top of screen for toggles.

I don’t have any info about sliders, so aint put them yet.

Any good idea would be apreciated, ask for something…

[kurte]

Looks great. On mine I have also 4 push buttons used to configure stuff (next screen, previous screen, enter, escape). I don’t remember if your display is a touch screen? If so you can probably do it with that, otherwise you may want to think about how you wish to choose things, like which robot to talk to, etc…

Kurt