rosserial over 433mhz 3DR radio
Hello,
I am using rosserial tru a serial cable. Recently I made a change in my setup to use a 3DR radio on both ends. I setup the radio to 115200 bauds, checked communications by other means, and then run my ros setup, and although it gives me a lot of errors, it "kind of" works. By "kind of" I mean it works intermittently. For example when using twist_teleop, you have to press and keep pressed the button, so it takes the command. the broadcasted odometry data will be only shown intermittently.
The error lines are below pasted below:
=============================================
wrong checksum for topic id and msg
Mismatched protocol version in packet: lost sync or rosserial_python is from different ros release than the rosserial client
Protocol version of client is unrecognized, expected Rev 1 (rosserial 0.5+)
Serial Port read returned short (expected 713 bytes, received 636 instead).
Serial Port read failure:
Packet Failed : Failed to read msg data
msg len is 93
Lost sync with device, restarting...
Setup publisher on odom [nav_msgs/Odometry]
Setup publisher on /tf [tf/tfMessage]
Setup publisher on odom [nav_msgs/Odometry]
Setup publisher on /tf [tf/tfMessage]
==============================================
none of those errors above happen when using a wired link. I believe it is due to the quality of the wireless link. And I am just broadcasting odometry data.
Any ideas or reccomendations how to make this kind of setup work?
Best regards, C.
rosserial assumes that the connection is duplex (sending and receiving at the same time), not simplex (alternate sending or receiving), so check that.
Hello:
The radio I have is: http://ardupilot.org/copter/docs/comm...
So it appears that they are half-duplex, but have a buffer to make it work like full duplex.
Is there a way to make rosserial operate in half-duplex?
Best, C,
Probably not. You could try if you have any control over the buffer of your rf modules. But I havn't got 100% success yet with mine.
I think I should clarify a bit. What I have observed on my radio link was: 1) Peer A starts to send a message 2) At the same time Peer B also wants to send a keep alive. 3) Keep alive does gets lost as Peer A is in transmit mode.
To work around that one would could implement a procedure which would give both peers alternating transmit slots. As rosserial does not do that at this moment I'ld suggest to implement your own protocol.
When you mean Peer A, Peer B, you also mean a control station right?
Another thing that I did not understand: why does rosserial need this much bandwidth, just to send simple odometry? I read elsewhere it requires >60kbps
On of the peers is your PC with rosserial_python the other peer is the embedded controller running rosserial_client