Long Range Machine Control System

LoRa + ROS Full Duplex Peer to Peer Data Transceiver Array with Onboard High Precision Satellite Positioning

Similar projects worth following
As global warming increases and our planet continues more and more to resemble Mars, there may well be a need for Earth based rovers to search out water supplies or help herd goats on ever increasing expanses of semi -desert. Also, many rural parts of the world do not have access to 3G/4G cellular data connections and Starlink type systems are currently prohibitively expensive. The solution where I myself live seems to be to use an array of custom generated radio waves to transmit data back and forth to my loyal rovers and other stationary machines / devices .... or even fellow humans.

Designed to control machines in post apocalyptic environments, or just where I actually live, these gadgets integrate 4 or more LoRa radios controlled by Mega 2560 MCUs with a Raspberry Pi via ROS (Robot Operating System) so that messages, or data, can be sent over long distances in such as way that outgoing messages do not block incoming messages - it's true duplex. Most LoRa modules are only half duplex, in that simultaneous receive (Rx) and transmit (Tx) is not possible. It might well be possible to use a 'Concatenater', but that will be something for the next upgrade.

There's always a compromise between range and data speed and this system is not designed to be fast or 'Real-time' and there is significant lag between sending and receiving messages. Imagine we are controlling a rover on Mars, but rather than 15 minutes of lag, we have about 10 seconds. In a disaster area such the aftermath of hurricanes, where key infrastructure has been destroyed, this system could be used to relay encrypted messages back and forth to other distant locations without the need for setting up any kind of network, which is what is meant by the term 'Peer to Peer'. However, this does not mean that simple networks could not exist as time after the singularity ticks on.

Each module also has Joysticks and a slider pot so that we can control our Mars Rover from Earth. Obviously, the Rover or 'Dog' does not need the joysticks unless some aliens need to control similar machines on Earth. There is also a vast array of blinkenlights for diagnostics and general notification that stuff is happening, which may also be quite entertaining for the Martians.

This equipment can be used to transmit and receive data and verify the integrity of the data by making call backs. But also can perform actions based on what the data presents. For example, if water levels in a river are determined to be getting to critical levels, various alarms and messages can be created via ROS and sluice gates could be opened to divert water away from settlements..

ROS is installed on the Mega 2560's as the 'Rosserial' library and on the Raspberry Pi as ROS Melodic. Communications between the 3 modules happen via USB and ethernet via a router. Other features on the gadgets include a choice of two medical grade power supplies, an RF amplifier for the LoRa Tx and a choice of two surface mounted RF band pass filters.

This system is designed to be as self contained as possible and so 3G/4G/5G was not considered to be a viable option. We did actually try WIFI a couple of years ago, but the neighbors started complaining about machine data interfering with their Netflix. They obviously did not realise that there would be no more Netflix after the climate change Armageddon, but never mind. The problem was that the range of the WIFI was very poor without using high powered RF amplifiers. Also, I live on an island in the middle of the Irish sea and 4G connections are very poor / non existent and, again, this kind of infrastructure would easily be destroyed by hurricanes, hackers, emergent Ai intelligence or invading aliens.

Being realistic, it's probably not going to be possible to put a Starlink system on each and every Rover (dog) and it does take at least 3 Rovers to effectively herd goats. Maybe this would be possible in 5/10 years in the future but my cryogenic sleep chamber has been malfunctioning so I chose to use the tools that were available to me right now and within a reasonable budget. Luckily, data from positioning satellites is completely free and fairly straight forwards to process. This project takes terrestrial positioning to the next level by incorporating a positioning correction system which sends data to the Rover from a stationary reference point. Goats can now be herded to a precision of plus / minus 10mm !

Main Modules so far:

  • Nest (Mission Control Centre):
    • Raspberry Pi ROS Master ..... communications with the Arduino modules via ROS
    • Raspberry Pi ROS Slave...
Read more »

  • Microcontroller Choice

    An Ugly☠Pirate06/18/2022 at 14:00 0 comments

    Well, actually, in the end the Heltec ESP32 module could not be made to work with ROS and LoRa simultaneously :( I'm sure it's possible, but I ended up spending too much time on it and decided to go for an Arduino Mega 2560 Mini Pro instead, which worked straight away without any messing about. The end solution is a bit more expensive as there is no onboard LoRa chip, but time is also precious!

    It's now time to get another run or PCBs made and incorporate a few more handy features such as the ability to turn the power on/off to the RPis from one of the micro-controllers and get auxillary power via Type C USB cables.

  • Testing Heltech LoRa ESP32 Modules

    An Ugly☠Pirate06/14/2022 at 10:39 0 comments

    Although the name suggests these devices might be hellishly difficult to work with, it actually only took me 2 days to get it working with ROS via WiFi and initialise a LoRa session. The boards look incredibly well made and, best of all, they have a blue LED on GPIO pin 25. To get all features on the device working Heltech have produced their own IDE tool chain and part of it is used in the Arduino IDE and, strangely, this software only works on an AMD 64 type PC running Ubuntu v.20. Ubuntu 18 does not have the USB driver required, although I guess they could be tracked down and installed manually. It was also tested on a Raspberry Pi, but failed. Having data sent to the ROS could be a lot less hassle although I'm wondering how many of these devices can be used at the same time without clogging up the local WiFi radio spectrum. Should I rebuild the PCBs with slots for 10 of these gadgets ..... or maybe 20?

  • Data Now Flowing Through the LoRa Airwaves

    An Ugly☠Pirate06/05/2022 at 16:14 0 comments

    Finally, after many days of coding and decoding, I got data flowing from the Nest through the LoRa airwaves to the Dog. Not only that, I managed to get a proper 'Fix' on the Dog Ublox ZED F9P. At the beginning, it took about 120 seconds for one chunk of fix data to get sent, which equates to about 3,000 bytes. These chunks were split up into about 85 packets of about 45 bytes each. After messing about with the LoRa code, and various settings such as spreading factors and bandwidths, I got the chunk transmit time down to about 4 seconds and only then did the F9P get a proper fix. I'll now be slowing increasing the spreading factors until the transmit time starts to get affected and the Dog starts to detect missing packets and bleeps it's buzzer at me, but I've got a feeling that the system is already running at full tilt. However, even if this is the case, all is not lost as it's more than possible to add a whole load more radio modules to the system - dial it up to eleven! (One for Dog Tx and ten for Dog Rx and ten for Nest Tx and one for Nest Rx). This would give 10x the speed and the opportunity to increase the spreading factor for longer range.

  • Accurate Satellite Positioning

    An Ugly☠Pirate05/31/2022 at 09:40 0 comments

    Probably the most important task for long range machine to machine communication is to know exactly where our roving machines are, and even the stationary ones. In many cases, ordinary GPS/GNSS satellite positioning would be fine, giving an accuracy of about 2 metres for a moving machine. The accuracy of a stationary machine can be much better if thousands of readings are averaged over 24 hours or even a whole week. To get the positional accuracy of moving machines to an acceptable levels, correction data needs to be sent to the machine (Dog) itself for it to calculate an accurate position for itself, which can then be transmitted back to Mission Control (Nest). The idea of correction data is a slightly abstract concept and has a few logical fundamentals to be aware of:

    1. Data sent from satellites travel through the Earth's atmosphere, which causes the time component to vary slightly causing a subsequent small error.
    2. This error can be largely corrected for a stationary module in the Nest by taking an average of many thousands of readings over a whole week.
    3. We now know the exact position of this one module located in the Nest.
    4. The Dog is roaming around within a few miles from the Nest and so the data from the satellites goes through pretty much the same chunk of Earth's atmosphere as the Nest.
    5. The error for the Dog and Nest is pretty much the same.
    6. The Nest module knows exactly where it is, so it also knows the error at any given time.
    7. If the Nest can send the error details to the Dog, then the Dog would also know the error and so be able to correct it's own position.

    Fortunately, the Ublox module does a lot of the work for us and all we have to do it to configure it to export the correction data if the module is in the Nest and import it if it is on a Dog. Configuration files are available in the Github repo. The Ublox configuration is done on a Windows computer running the free Ucenter app, which is quite vast and may take a bit of time to navigate - but it's quite fun to see all the satellites buzzing about the sky and the true positional accuracy of our machines.

    Normally, we'd just get a radio module for the Ublox module, bolt it on and job done, but I chose to take control of the correction data and route it into a LoRa module for long range transmission. I wanted to have ROS enabled in all the machines, so it was logical to get the data moving trough the ROS, which proved to be quite 'interesting'. In a previous iteration , we used RTKLIB and it's str2str app, which worked really well through WIFI, but with very limited range. Getting the data moving through ROS meant changing it from ASCII characters into HEX format, changing HEX into a string, and then splitting the HEX string data into packets of size 45 characters each. The data is given a 'start' and 'finish' flag and then gets relayed to an Arduino MCU through ROS which is then transmitted through LoRa, one packet at a time with additional data such as signal strength and such like bolted on. It's quite satisfying to see the data come over on the Dog and the process for getting the received data into the Dog's Ublox module is just a matter of reversing what was done in the Nest.

    If anybody's interested in the actual code that handles this, it's located in a file called: in the custom made nest_slave_talker_listener ROS package. Serial data is handled very nicely by the Python Serial library.

  • Can documentation be fun?

    An Ugly☠Pirate05/29/2022 at 10:13 0 comments

    Normally, in the recent past, I'd create a device or machine with all manner of fancy Ai equipped all seeing, all thinking, super fantastic sensation that even worked really well. But, and this is the big one, by the time I'd finished, I had pretty much no idea what all the components were, especially when it came to interactive files in the software stack. In one project, I ended up with a pretty crazy diagram showing how all the files interacted, but it just was not properly accurate for my liking.

    One of the problems is that I like to work really fast and focus entirely on getting the project working. This time I am taking a more leisurely approach and am trying to create enough documentation to enable myself, never mind anyone else, to see how it was all pieced together. To do this, the documentation stages need to be enjoyable.

    Due to previous experience in this particular field, I pretty much know 95% that this project is going to work really nicely as it is built on top of other previous successful projects. I believe that by doing the project a bit more slowly and methodically could be MORE enjoyable and taking a bit of time out to do some documentation could actually make it MORE fun and rewarding.

    The first step in this new adventure is to keep track of the software stack as more files are added and not to lose track of how files interact with each other. Currently, as of May 2022, the stack is quite simple but, as the project evolves, this is likely to change quite radically. If I start iteratively updating the stack diagram after each major change, can I accurately keep track of it all? I am going to try, at least!

    The diagram below is the second iteration - it's the second diagram I have produce so fat detailing the components of the stack. It's going to get much bigger as time goes on.

    The eager eyed amongst us will notice that the stack is split into 2 halves and the right hand side is currently empty. So far, I've been working exclusively on the 'Nest' which is my own term for the control centre, or 'Mission Control' in NASA lingo. The choice of words for parts of the stack and the system in general is absolutely crucial as in previous projects I saw terminology, especially with regards to satellite positioning, deteriorate into a travesty of inappropriate descriptions. Other projects ended up with multiple use of the word 'base' which resulted in truly incomprehensible instructions. 'Base' is a banned word in this project and all parts of the system are to be described by objects in the animal kingdom including 'Nest', 'Dog' and 'Snout'. Nest is used to indicate that the device or part of the stack is physically located in the mission control room. We could then have Nest_Master to indicate that the device is the master in the ROS operating system in the Nest. Dog is a roving machine and dog_snout is the front of the machine. Trust me, this form of nomenclature is infinitely better than what seems to be the industry standard.

    In the diagram above, the most crucial details of the stack in the nestmaster and nestslave are shown. Both these devices are Raspberry Pi V4's. There's also currently just one Arduino Mega 2560 called arduino_master_tx. I should probably re-name this to arduino_nest_tx in the next iteration of the documentation for extra clarity. There's also going to be an arduino_nest_rx to handle incoming radio waves from the dogs and any other machines out in the wilderness.

    Another thing that might be slightly interesting, is that I will be backing up the SD cards or SSD's or whatever, regularly throughout the development so that there will always be at least 2 copies of each Raspberry Pi system. Also, the plan is to have fully duplicated SD cards (or whatever) for the main Raspberry Pis so that, for example, the Master SD card will contain all the files for all the Masters that exist in the entire ecosystem. Logically, I should probably change the word nestmaster to masternest, this...

    Read more »

View all 5 project logs

Enjoy this project?



Nazwa wrote 04/01/2022 at 20:28 point

is possible make connection sound modem? for example for baofeng?

  Are you sure? yes | no

An Ugly☠Pirate wrote 04/01/2022 at 20:48 point

Maybe, but the project will concentrate on data only at this stage.

  Are you sure? yes | no

Nazwa wrote 04/03/2022 at 16:19 point

I talk about data trought audio modem.


  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates