lukasz.chinczewski
Posts: 7
Joined: Fri Apr 11, 2014 5:25 pm

Control object for long distance

Wed Apr 16, 2014 12:26 pm

Hello,
I have a problem. Now I wonder how to control a robot operated by the Raspberry Pi. Control has to be from a computer located about one kilometer away. The distance between the two positions is in difficult terrain.
What kind of technology, what solution should I choose and use to the best effect?

Thanks in advance for any information.

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Control object for long distance

Wed Apr 16, 2014 12:52 pm

Hi,
lukasz.chinczewski wrote:Control has to be from a computer located about one kilometer away.
What is required link speed ?

If there is no video content, but just some control/sensors feedback data, then there are various simple-to-use RF transceivers (for example, XBee has been mentioned also here several times) which can solve this problem. They have ordinary data interfaces (like UART and SPI) and various guidelines exist how to use them.

If you need to transmit also video... hmm... then I'd use two links - one would be slow-speed control link with transceivers mentioned above, where the second link would be dedicated only to video.


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

lukasz.chinczewski
Posts: 7
Joined: Fri Apr 11, 2014 5:25 pm

Re: Control object for long distance

Wed Apr 16, 2014 4:51 pm

Hi Ivan,
Do you think wifi would be suitable? Is it better to use radio transmitters type SATEL?

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Control object for long distance

Wed Apr 16, 2014 7:57 pm

Hi Lucasz,
lukasz.chinczewski wrote:Do you think wifi would be suitable?
I'd not pick WiFi.
The main reason is that you need a directional antennae (and line-of-sight between PC and the robot) to have kilometer-range WiFi link. But, since your robot is moving (I suppose), the directional antennae doesn't make sense. The possible solution would be to have non-directional antennae then (and here again comes "but"), but then you'd need to drastically increase RF power, what is not allowed by authorities.
lukasz.chinczewski wrote:Is it better to use radio transmitters type SATEL?
Definitely.
Check throughput.


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

lukasz.chinczewski
Posts: 7
Joined: Fri Apr 11, 2014 5:25 pm

Re: Control object for long distance

Fri Apr 18, 2014 6:48 am

Ivan're really helpful, thank you;)

Ok I got it http://www.satel.com/product/satelline-3as-869.
What should I do then. Immediately after connecting to the PC and Raspberry?

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Control object for long distance

Fri Apr 18, 2014 10:41 am

Hi,
lukasz.chinczewski wrote:Ok I got it http://www.satel.com/product/satelline-3as-869.
What should I do then. Immediately after connecting to the PC and Raspberry?
Communicate ? ;-)

If you pick these Satel's radio, you get serial (RS232) link. You need to define a communication protocol -> what commands look like (=package structure + syntax), do each command require response from the other side, what is error detection mechanism, etc.)...

For example, to move forward, you could define "*MF<n>;" command and to move forward 500 steps, you'd send "*MF500;", to turn right for 45 degrees you'd send "*TR45;", to go forward and backward 100 steps you'd send "*MF100;*MB100;" etc. After each command received the robot would return acknowledge, for example "*OK;".

I personally prefer CRC checksums to be sure that the content is valid. For initial testings they are not mandatory, but when you solve other issues, then you should add checksums to each packet.
Additionally, you'd probably need to have a timeout&retry mechanism - if receiver gets a command with invalid CRC, it ignores it and since the transmitter doesn't receive acknowledge within predefined timeout interval, it resends this packet.... and (for example) after 10 failed attempts, it alerts that the robot is out of range, or run out of batteries, etc.
Uncovered case here is when the command is received successfully, but the acknowledge is not. To avoid repeating executing the same command several times, you should add a counter in packets - when the robot receives a packet with the same counter value as previous one, it can just acknowledge it, but not execute (because the reason for this repeated packet is that the acknowledge was not received first time)...

On this "protocol layer" you can implement various things (this is nice task to feed a creativity ;-) ) and the protocol can be improved within several iterations, according to the issues you're facing.

One not very obvious nice-to-have feature is (if radio allows this) to exchange information about RF signal strength. By adding this information into packets, you inform the other side how strong its RF signal is. With this feature you drastically prevent cases to lose control over the robot - when RF signal strength falls below some level (which is still sufficient for the communication), you get this information and interrupt current control procedure, but you still have the ability to control robot, to execute a kind of recovery scenario, etc.


Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

Return to “Troubleshooting”