DIY Remote Control XBee controller for Robotics... - RobotShop Forum

Putting robotics at your service™

Free shipping on orders over $75

DIY Remote Control XBee controller for Robotics...

Print view Share :
Previous topicNext topic

Page 2 of 35 [ 511 posts ]

1, 2, 3, 4, 5 ... 35
New ( offline )
Posts: 5
Posted: 2009-09-15 09:23 
Ok, now to correct some of what ive previously posted. A day of experimenting....nows the time for those really smart electronics guys amongst you to come out and add some knowledge, and correct any of my postulating.

So, something i got wrong that is blatantly obvious is that the LED's on the regulated xbee boards are set to go on when the signal lines go low, not high so they cant be helping in the level shift issue at all.

Fact is that the sparkfun xbee regulated board doesnt do any level shifting. If you wire it directly to the pin of an atom, even the 3.3volt pin it does not work. The signal LED flickers, but nothing transmits. I suspect what is happening is that too much current is going into the xbee causing it to overload and protect itself, but i havent gone deeper into the inner workings of the xbee to confirm this. It appears from the notes of others that if you limit the input current, the xbee will work on 5 volt logic. But for the sake of one more resistor to make a voltage divider, you get both. So tomorrow im modifying the board with a voltage divider to confirm this theory. If this works, its still a good option. Will tell you tomorrow how i get on.

Working on code for doing the controls also, but got nothing good enough to show yet. I will persist with doing this without flow control first, as for me the buffering capability does not help. If it buffers, my heli is not getting instructions = bad. Helis need control inputs continuously to keep them flying. Even a pause for half a second is not good. This may mean in the end that an xbee is a bad idea for my heli - so be it, but i would have at least tried. I will potentially use dual xbees for bidirectional comms so that the controls are not interrupted.


User avatar
Guru ( offline )
Posts: 4942
Posted: 2009-09-15 10:55 
rotorman wrote:
Fact is that the sparkfun xbee regulated board doesnt do any level shifting. If you wire it directly to the pin of an atom, even the 3.3volt pin it does not work. The signal LED flickers, but nothing transmits. I suspect what is happening is that too much current is going into the xbee causing it to overload and protect itself, but i havent gone deeper into the inner workings of the xbee to confirm this. It appears from the notes of others that if you limit the input current, the xbee will work on 5 volt logic. But for the sake of one more resistor to make a voltage divider, you get both. So tomorrow im modifying the board with a voltage divider to confirm this theory. If this works, its still a good option. Will tell you tomorrow how i get on.

Yep, others are better at the electrical stuff. But may not be important as it appears like Sparkfun has discontinued the product. Trossen still appears to have some in stock, but at least for me clicking on the schematic link fails... But there are other boards that do have proper level shifting, such as the Selmaware ones which are pretty large. Another one I have found is: http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 I don't know anything about them, but...

rotorman wrote:
Working on code for doing the controls also, but got nothing good enough to show yet. I will persist with doing this without flow control first, as for me the buffering capability does not help. If it buffers, my heli is not getting instructions = bad. Helis need control inputs continuously to keep them flying. Even a pause for half a second is not good. This may mean in the end that an xbee is a bad idea for my heli - so be it, but i would have at least tried. I will potentially use dual xbees for bidirectional comms so that the controls are not interrupted.


Buffering the data can be a very good thing if it keeps you from losing a packet. I am not talking about holding the data for a second or two at a time, but maybe a several miliseconds. However currently I am not sure about using the RTS line. The beta version of studio I have appears to work as I would expect it, however when the RTS signal comes back up the XBEE still sends a byte or two before it stops as I believe on a PC the RTS means I am about full.

I tried again to change my Transmitter code to use RTS, but my packets kept getting screwed up (out of alignment with data bytes lost). I have a couple of options:
1) If it continues that two bytes are lost each time, I could add 2 bytes of fluff at the end.

2)Go back HSERIN and take care of the LCD problems (I have the code for this)

3)Try without any flow control. Since currently I am getting prompts from robot could try to time it to get them correctly.

3a) Like 3) but with hack to maybe change which IO line the RX is on to one with interrupt, could send character that triggers interrupt, then wait a bit and then send packet. Some complications would be to make sure the first character got sent out (timeout on xbee) before the others of the packet was sent). I used something like this on the TV brat in S_IN...

That is all for now.
Kurt


User avatar
Guru ( offline )
Posts: 4942
Posted: 2009-09-15 13:19 
Quick update: I received email from Sparkfun. It looks like the part has not been discontinued and is back up on their website. For some reason I can not load their schematic from website but they did send me one in email.

It appears like they are relying on the LED and a 1K resistor to lower the voltage...


Guru ( offline )
Posts: 4282
Posted: 2009-09-15 13:25 
Hi Guys,

I don't know if I have much to add at this point, but I would not route 5v logic signals into 3.3v logic without a proper level converter. I've designed boards with mixed logic, and it's a hassle! I was lucky enough to be able to find 5v tolerant parts in one instance; another interface was accomplished with the two-resistor voltage divider mentioned.

The fact that the product is discontinued makes me think they realized that the design was faulty.

diversity XBEE receivers? Could work! I remember the DIY receiver stuff had a second receiver, That's the first time I've seen that approach outside of commercial or Amateur Radio applications!

Looking forward to hearing more on the implementation of XBEE!

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


New ( offline )
Posts: 5
Posted: 2009-09-16 20:33 
Ive got my xbee control system now up and communicating, just using a single channel at the moment for simplicity.

The sparkfun xbee carrier boards seem to work just fine (now that ive got everything there). I currently have them with 5 volt logic directly into the input lines (for the moment anyway - time will tell if it is detrimental.....). I experimented with a voltage divider setup on the input, and it seems that (as i found before) 3.3volt logic can be a little marginal to drive it.

I am surprised this is working, as there is nothing that i can understand that is reducing the logic level. The 'DIN' and 'DOUT' leds are not doing anything - they are actually wired the opposite polarity so they come on with a 0 (0volts) and are driven off the onboard 3.3volt regulator. Im sure ill find out with time if this is healthy. To be honest, ive made some real stuff ups before and wired the xbee up accidentally the wrong way (data in the data out line etc) and they seem remarkably tough. And they should be - xbee's are matured technology and have been around for a few years now in industrial applications.

So, up to you guys i guess, but ill stick with these - they are under US$10 and they are only as big as the xbee, perfect for what i want.

One thing to note is that to me the board is a little confusing with its labeling of the led's. The wireless 'receive data' led is labeled 'DOUT', as in refering to Data out at the pin, not data out from the wireless. Had me a little confused.

Anyone else other than kurte actively working to get something going?


User avatar
Guru ( offline )
Posts: 4942
Posted: 2009-09-17 09:39 
Hi Alan,

The product is back up on their website and now the link works for the schematic again http://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Regulated-v10.pdf. As far as I can tell they are simply relying on the resistor and LED to take care of voltages. I remember when I was playing with a propeller processor, they would often simply use a resistor when hooking up a 5v device to one of the inputs on the propeller. That probably is not as safe as using a proper converter...

Hi again Rotorman. I have not tried my sparkfun versions yet, but glad you got yours to work. I have been playing with my transmitter/receiver code and trying to get better handshaking to work. Also still experimenting between using flow control or not or use HSERIN or not. My current version is using HSERIN and my own SEROUT function.

I think if we can get this to work well there are several others who will be interested, but I have a lot of work left to do...

Kurt


Guru ( offline )
Posts: 4282
Posted: 2009-09-17 14:05 
Hi Kurt,

Yeah, I'd feel more comfortable with at least a resistor divider. What do the LEDs do for the conversion? If DIN goes high, no current flows through the LED. Now if they'd used the DIN signal to ground for an LED, it might have worked as a resistive divider.

And you're right, your improved HSERIN and SEROUT functions could also be useful for my blueTooth interface.

Alan KM6VV

kurte wrote:
Hi Alan,

The product is back up on their website and now the link works for the schematic again
http://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Regulated-v10.pdf.

As far as I can tell they are simply relying on the resistor and LED to take care of voltages. I remember when I was playing with a propeller processor, they would often simply use a resistor when hooking up a 5v device to one of the inputs on the propeller. That probably is not as safe as using a proper converter...

Hi again Rotorman. I have not tried my sparkfun versions yet, but glad you got yours to work. I have been playing with my transmitter/receiver code and trying to get better handshaking to work. Also still experimenting between using flow control or not or use HSERIN or not. My current version is using HSERIN and my own SEROUT function.

I think if we can get this to work well there are several others who will be interested, but I have a lot of work left to do...

Kurt

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


Guru ( offline )
Posts: 2158
Posted: 2009-09-17 16:14 
Uh not really following the discussion too much but with respect to the diode in the DIN line of the sparkfun schematic you linked, the diode effectively is a wire-AND for the DIN pin. It relies on pull-up current established by LED+resistor plus the pull-up resistor internal to the XBee module (on by default, see the PR command description on or about page 49 of the XBee manual) to pull the DIN pin back to a high state unless a host is actively driving it to a low state through the diode.


Guru ( offline )
Posts: 4282
Posted: 2009-09-17 16:42 
I didn't see anything about it in the 2.5 Pro XBEE manual I came across (wrong manual).

I can see the wire-AND function, but still nothing to limit the voltage of the incoming signal. OK, a diode drop. Can the XBEE sink much back into it's power lines via an input pin (protection)?

Alan KM6VV

EddieB wrote:
Uh not really following the discussion too much but with respect to the diode in the DIN line of the sparkfun schematic you linked, the diode effectively is a wire-AND for the DIN pin. It relies on pull-up current established by LED+resistor plus the pull-up resistor internal to the XBee module (on by default, see the PR command description on or about page 49 of the XBee manual) to pull the DIN pin back to a high state unless a host is actively driving it to a low state through the diode.

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


Guru ( offline )
Posts: 2158
Posted: 2009-09-17 23:36 
the cathode of the diode is attached to the incomming signal. when the incomming signal is > 3.3V the diode is in reverse bias not forward so the DIN pin is right about 3.3V. when the incomming sinal is 0v the diode is forward biased and the DIN pin is pulled to a diode drop above ground.


Guru ( offline )
Posts: 4282
Posted: 2009-09-18 00:51 
Because of the internal pull up?

That would do it!

Alan KM6VV

EddieB wrote:
the cathode of the diode is attached to the incomming signal. when the incomming signal is > 3.3V the diode is in reverse bias not forward so the DIN pin is right about 3.3V. when the incomming sinal is 0v the diode is forward biased and the DIN pin is pulled to a diode drop above ground.

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/


User avatar
Guru ( offline )
Posts: 4942
Posted: 2009-09-23 11:52 
Quick Update:

I have been making some reasonable progress here. I am rolling my own handshaking between the controller and a robot, which is starting to work OK. I still have a few issues to work out to make sure that it is reliable. I am currently always sending/receiving packets even though nothing has changed, which will change soon.

For now I have settled on using HSERIAL to communicate with the XBEE. I have a few assembly language functions to replace some of the functionality of HSERSTAT which at times resets the processor. As I now have the xbees running at 38400 I am using my timer based serout to output to the LCD. I may try bumping up the baud rates to 57600 to see how that does...

I have just started to take a diversion in the transmitter code right now. For now I am using the "D" key on the keypad to cycle through a few different pages of displays/configurations. So far I am thinking fo doing 4 pages.

Page 1: will have the same stuff as now.

Page 2: Top line will show when a slider/joystick changes values, bottom line will be reserved for data transmitted from robot...

Page 3: Will allow me to choose who to send to (XBee DL). That is you will be able to hit keys 0-9 to change the DL. Will need to expand on this later to make it more configurable if you have multiple robots with multiple controllers in the same place... Could do a Node Discovery and maybe have some Bind Function that the Robot/Controller maybe exchange 64 bit unique address...

Page 4: Thinking of a calibrate function. Have users move joysticks/sliders to mins and maxs and leave at center point have the code calibrate the ranges...

So far I have put one of the Sparkfun XBEE boards on my old TV brat and it has taken a few steps with the updated code. Need to better handle how I am timing out the conversations... Soon will be updating my MechBrat who now has two guns mounted and I now have the pico switches to wire up...

So now back to having some fun
Kurt


User avatar
Guru ( offline )
Posts: 9256
Posted: 2009-09-23 12:08 
Sounds great Kurt! We hope to be able to follow along soon. Can you tell me which parts from Sparkfun I need to get so we can try it?

Would this work.
XBee 2mW Series 2.5 Chip Antenna
http://www.sparkfun.com/commerce/produc ... ts_id=8691

And one of these guys?
XBee Explorer Regulated
http://www.sparkfun.com/commerce/produc ... ts_id=9132

And do I just need one for bot and one for radio? Thanks!!!

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


User avatar
Guru ( offline )
Posts: 4942
Posted: 2009-09-23 12:38 
Hi Jim,

Currently I am using series 1 XBees as their interface is a bit easier. I have a couple of the chip antenna one as well as a couple of wire Antenna http://www.sparkfun.com/commerce/product_info.php?products_id=8665

You should also be able to use the series 1 Pros which are 60mw http://www.sparkfun.com/commerce/product_info.php?products_id=8690. Not sure how long the batteries may last...

Also I am not sure about the range differences between the chip versus the wire versus the external. I think I read someplace that the chip has a shorter range... But could be wrong.

I do have a couple of the series 2.5 Pros, which I may try out later. I will need to figure out more the differences of topography between series 1 and 2.5...

Yes my brat has one of the XBee exporer regulated that you called out, have a second one that will be going to Mechbrat or the Rover or the CHR-3...

Yes you need just one per the transmitter and one per robot that you wish to control.

Kurt


User avatar
Guru ( offline )
Posts: 9256
Posted: 2009-09-23 13:29 
Hi Kurt, thanks for the info. I will pick up some stuff to play with. 8)

Are you implementing error correction on this. Basically send a character stream and checksum and the receiving end asks for the data again if the checksum fails. Or something like that. lol

Not sure if this is necessary or if it adds significantly to the difficulty.

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


1, 2, 3, 4, 5 ... 35

All times are UTC - 5 hours [ DST ]. It is currently 2018-04-26 20:58