Bi-directional communication with Parallax 433mhz transceiver

Kelvin

I am using the 433mhz rf modules from Parallax to communicate with my boebot.· I have everything up and working fine, thanks to the excellent code examples.· I am trying to write code for the basic stamp connected to the pc, and the basic stamp on the bot, that will be enable them to communicate both ways, not just one way.· My code has three main functions:

1.· Control the bot manually from the PC
2.· Let the bot run in an autonomous state
3.· Switch between case #1 or #2
4.· During either case #1 or #2, send sensor data from the bot back to the pc.

Switching between case #1 and Case #2 will be accomplished by having the bot listen for a command from the pc.· For now for #4, I just want the values sent back to the debugger window.· I will worry about putting a VB or C++ front end on it later.

I am using examples from the boedar project, and this thread as examples.· My question is this:· Do I need to create some kind of complicated communications protocol (acks, checksums, wait for transmissions, etc) or can I just use brute force and hope the transmissions don't step on each other?· I have figured out that I need to use the PDN pin on the tx/rx modules so I don't cause interference, but I am hoping for some easier approach than designing a complex communications protocol.

Thanks.

allanlane5

You probably need some SIMPLE handshake, to insure the BS2 gets data. The BS2 will ONLY recieve data when it is sitting in a 'SERIN' statement.

So a simple:
PC

---

BS2

'D' ---- 'A' '

---

PC sends "D", BS2, if it GETS the "D", replys with "A" for 'ack'.

"PC Data String" ---- 'A', "BS2 Data String"

You could have the BS2 send an "N" for 'nack', or to request action from the PC.

In use, when the PC wanted to talk to the BS2, you'd send a "D"
once every 10 milliseconds, or once every 100 milliseconds. You'd have the BS2
wait in a SERIN routine (with a timeout of 10 milliseconds) for the "D". If not found
(most of the time) the BS2 would go on with its normal processing. If found, then
the BS2 sends back the "A" and waits for the rest of the PC's message.

Tom Walker

...and you ARE using TRANSCEIVERS, right? If you are only using a transmitter and a receiver, there is no way for the 'bot to send data back to the PC...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Kelvin

Tom: Yes, I am using the tranceivers (I count four antennas total). Thanks for asking the clarifying question - I am completely capable of making simple mistakes, so I appreciate the double check. The code examples provided with the tranceivers are the same code examples that are provided with the single receiver/transmitter pairs, so that piece of code is not much good for trying two way communication.

Allan - your post was extremely useful in helping me think about the problem. I will work on a simple ack/nack protocol as you suggest. In the code I am using, in the manual mode I hold down the 'w' key to move forward. I am worried that while holding down the 'w' (or any other nav key), I won't get sensor data back from the bot. I think if I build the timings in my loop correctly, and let the servos drive themselves for a long enough period that I can loop back and send a piece of sensor data, I should be OK.

Thanks. If anyone else would like to weigh in, feel free.

Pezi_Pink!

Hi Kelvin,

Strangely enough I am currently working on the identical same thing, except I'm using my own robot and not a BOE.

What Allan suggests above is certianly the correct approach for this, and is very similar to what I ended up with.· One thing I would suggest though, is instead of holding down your forward key, you could send the command once and have the boe change states to reflect what it is doing, this way you don't have to repeatedly send the bot the same same data.

On my robot I'm using motors so it will be slightly different, but I'm using PWM to vary the acceleration of the back wheels.· At the moment the bot starts off in a stationary state.· If you press the forward key, the bot sets its state_forward bit to 1 and increases the PWM duty to the next pre-determined value out of 4.· It will then travel forward at this speed until it is given a forward command again, in which case it will increase the PWM duty, or backwards where it will decrease the PWM duty, and ulitmatley stop and then the process is reversed, the forward state is set to 0, backward state to 1 and the acceleration works the same way backwards.· At any time it could also recieve a left or right command, in which case the states for left and right are set to reflect which direction to turn.· If you press left when it's already turing right, this striaghtens the wheels.· A sucessive left·command will then make him turn left.·

Basically I have the bot check for a new signal from the pc at the start of the main loop, if there is one then it modifies the states/variables accordingly.· Either way it then processes the movment loop which refreshes the motors based on the states.· This way you don't have to worry about holding down of a key to move and thus disrupting data being sent back from the bot.· On my bot, I have a Ping))) on a servo, and it scans about 80 "degrees" in front of it returning sensor data - I'm currently working on a way of sending this lot on the fly (preferably not whilst its moving :P ) as it's way too much variable space to use.· I have also yet to code the auto-roam function.

Maybe we can swap some ideas / tests and see what we can come up with?· Currently my system works, but it could do with some tweaking to ensure the radio communicatoins are always recieved on both sides....

Thanks!

Pezi

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beware the pink squirrel!

Post Edited (Pezi_Pink!) : 6/6/2006 11:37:14 AM GMT

Kelvin

Pezi -

Good idea on not holding down keys, although I am a bit concerned about leaving the bot in a movement state before I get the comm bugs worked out. It looks from your description of your state_forward state that you would not actually have a 'run-away' robot scenario. I am using a state machine structure as well, as discussed in this article:

http://www.bluebelldesign.com/Robot Subsumption DLC.pdf

(article is probably somewhere on the Parallax site also)

My main control loop looks like this now: (this is PBASIC)

Main:
gosub sense
gosub send
gosub move
goto main

One of the subroutines in 'sense' is 'listen', along with the usual IR stuff. I want to give the sense subroutine priority, as listening for instructions or knowing you are about to bang into something is important. I will add my Ping (1/2 price Vex clone from Radioshack) after I get the basic platform working. The 'send' subroutine is where data transmission is handled. 'Move' has 'auto' and 'manual' subs. My long term goal is to let the PC do the heavy number crunching to help the robot with autolocation, navigation (add a 'PC_controlled' sub to 'move'), and some special purpose tasks. I also don't need to worry about variable space this way.

The 'listen' and 'send' subs are where I need to work on the comm challenges we are talking about. I may create a whole comm sub, rather than bury part in the 'sense' sub.

I'd be happy to trade ideas, although I will warn you that with family/work/other demands my hobby coding time is randomly distributed, with sometimes 1-2 week periods of inaction. Also, my psuedocode is in much better shape than my real code. Right now I can switch between auto and manual navigation, and sort of get data back. Because of the comm issues, the switch from auto to manual sometimes has me feverishly hitting the 'manual' key until the bot responds, and I only sometimes get data back.

tech-mech

This is a subject that I am also interested in but I was going to use an SX28 to buffer the communications, there is example code in one of the SX books that I have.

One of my projects would use the same idea but communicate through a long wire.

What type of data packets are you using?

How are you mounting the radio boards?

I hope that I can contribute to this in the future.

I also hope my son can join in on this too. I will tell him about it next time we talk (he's in the Army)

Dale

Kelvin

I have not even designed a packet structure yet, as right now I am just trying to get the timing right so the send and receive subroutines don't take up so many processing cycles that the servos don't get driven properly. I am reading posts and code related to interrupts, multi-tasking (emulation, as the BS2 can't reallly multi-task), etc. to help get this right.

As for mounting, right now I just have the boards stuck into the breadboard on the boebot. I was wondering last night if I changing the antennas from a vertical to a horizantal orientation will affect performance in a negative way. I'll try to post a picture shortly. It is pretty much all stock Parallax stuff, except for a camera and light that I have added.

Kelvin

Here is my bot. You can see the two vertical black antennas of the transmitter and receiver. The silver cylinder on the front is a light I picked up from Lowes. The 2.6ghz wireless camera (the black cube at the front of the bot, mounted high) I got from Home depot for $99. It is called a 'securicam', and runs on a 9v battery.

Ryan Clarke

Kelvin,

Bot looks great, thanks for sharing.

Ryan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ryan Clarke
Parallax Tech Support

RClarke@Parallax.com