Not sure if this is viable. Looking for examples of prior work in this direction.
I have only cursory experience with RF and networks. Have a few simple mobile robots. Would like to use them as ground mobile AREDN nodes; automating and optimizing placement as much as I can, in that order. Willing to sacrifice performance and place additional nodes in order to make the deployment process as hands off as possible. The long term goal is to practice for disaster situations like Fukushima or where there simply isn't enough manpower available early in a remote location emergency. The immediate practical goal is to extend range from my wheelchair when camping or on other adventures.
Problem 1, automation: Initial node count and placement.
This is the site selection process we all go through using our best human judgement. I'd like insight on the specific computer accessible resources and processes (algorithm) you use, and any ideas to automate the process. Identify any necessarily human resources or judgments required.
In the disaster case, an endpoint is most likely the nearest roadside, rail siding, trail, airstrip, or navigable shore from the disaster site; staging area; fixed communication tower.
In my personal case, endpoints include wheelchair; vehicle in some parking lot; home.
Relay nodes will consist of the mobile robotic units. My plans only include ground based robots, but airborne drones placing solar radio relays in high locations make perfect sense in disasters.
Problem 2, location optimization: Where should a node move to improve Link State? Is it possible, using OLSR tables, coupled with topological maps, to generate a change of position vector which is expected to improve Link State?
There would exist some move cost function taking the change of position vector, expected link state improvement, volume of traffic through the node, time required to move, available battery capacity, and the move cost functions of neighboring nodes. If this node has better than marginal expected link state improvement at acceptable cost, then move.
Feed the change of position vector to the mobile robot, temporarily route traffic away from this node, save current location to prior location, move robot, save new current location, resume mesh traffic.
https://journals.sagepub.com/doi/10.1155/2012/614532
https://apps.dtic.mil/sti/pdfs/ADA475552.pdf
I have only cursory experience with RF and networks. Have a few simple mobile robots. Would like to use them as ground mobile AREDN nodes; automating and optimizing placement as much as I can, in that order. Willing to sacrifice performance and place additional nodes in order to make the deployment process as hands off as possible. The long term goal is to practice for disaster situations like Fukushima or where there simply isn't enough manpower available early in a remote location emergency. The immediate practical goal is to extend range from my wheelchair when camping or on other adventures.
Problem 1, automation: Initial node count and placement.
This is the site selection process we all go through using our best human judgement. I'd like insight on the specific computer accessible resources and processes (algorithm) you use, and any ideas to automate the process. Identify any necessarily human resources or judgments required.
In the disaster case, an endpoint is most likely the nearest roadside, rail siding, trail, airstrip, or navigable shore from the disaster site; staging area; fixed communication tower.
In my personal case, endpoints include wheelchair; vehicle in some parking lot; home.
Relay nodes will consist of the mobile robotic units. My plans only include ground based robots, but airborne drones placing solar radio relays in high locations make perfect sense in disasters.
Problem 2, location optimization: Where should a node move to improve Link State? Is it possible, using OLSR tables, coupled with topological maps, to generate a change of position vector which is expected to improve Link State?
There would exist some move cost function taking the change of position vector, expected link state improvement, volume of traffic through the node, time required to move, available battery capacity, and the move cost functions of neighboring nodes. If this node has better than marginal expected link state improvement at acceptable cost, then move.
Feed the change of position vector to the mobile robot, temporarily route traffic away from this node, save current location to prior location, move robot, save new current location, resume mesh traffic.
https://journals.sagepub.com/doi/10.1155/2012/614532
https://apps.dtic.mil/sti/pdfs/ADA475552.pdf
If we're already flashing consumer routers and WISP radios, perhaps flashing drones (which already have radios) with AREDN is in our future.
I think you could get a drone or robot to make some basic decisions about how to get where it needs to go, but the situation will be changing, and i think you'd need centralized C&C.
The drones can scout and provide interim access until a mobile platform could be dispatched to the optimal location.
I have a DJI Mini 2. They claim 31 minutes of flight time per charge. Lets say it is 22 minutes. We send it up, 398 ft directly above a given QTH, and it acts as a mesh hotspot. At the 20 minute mark, another Mini 2 takes off, flys up 398 ft, same mesh channel, and the 1st drone comes down to recharge, or have a battery swapped out.
If it landed on a landing pad that would recharge the drone, you'd probably need 5 or 6 drones to give each battery enough time to charge before it was tasked to fly again. (There are some videos on youtube of people who built charging landing pads.)
A human swapping batteries could bring down the cost, but that's not exactly "automation"
Getting a drone from A to B in clear air is mostly a solved problem. Ground rovers can sometimes share the same mission planning software by running the same autopilot hardware and a rover specific variation of the drone firmware. There are several mission planners in active development. https://ardupilot.org/ to name one. It makes sense to join one of those projects rather than reinvent that wheel. Do you have a preferred mission planner for your DJI hardware?
The decision where to go is easy for humans, it feels automatic, but it is difficult to put into code the reasons why we go this way, not that way, and why to wait... wait... go now! Stop. But it is possible.
The "motivation" for an AREDNbot is to improve the overall link state by changing its location, while minimizing battery capacity consumed.
The first thing we need to nail down is criteria for determining a better link state vs a worse one. I'm pretty sure the routing protocols already do that. But accessing that data for this new purpose could bog things down. So, step 1, don't make it worse.
For example, I do signal hunting from a vehicle using hitch mounted military tent poles for support of a NSM5 at about 9 feet. It works much better if aimed to the sides or back than over the vehicle roof. Generally you use the WiFi scan feature on "auto refresh" on the correct bandwidth and desired frequency of potential access points and drive to open areas looking for a signal to appear on the list. At that point, you park and can drive slowly forward and back until you get about -87 dB to appear on the WiFi scan. Then, you close that window and switch to the Chart program, choosing the target device and use audio feedback to find the maximum signal strength, and a solid connection to AREDN.
I don't have a background in the automation aspect, but the built in RSSI and LQ functions available from the chart interface are generally all that is needed to achieve a good aim initially. I like to set the distance manually, and sometimes reduce the power once the device has been in position for 20-30 minutes and see if I can achieve better throughput.
Interestingly, Ubibuiti devices also have a red LED on the back which lights up when connected, and sometimes you can use that for initial placement just moving around manually.
The most important thing for connectivity is clearance of ground clutter (trees!) to see the signal, so height is preferred. A small ground mounted robot with a device less than probably 5 feet of height is not going to clear ground obstruction or clutter from buildings, objects and trees. If the device were deployed on a rooftop, that might help, but isn't practical for a ground-based user in a parking lot.
Now another idea is that I have heard of is "pole climbing" robots. A very good deployment site for emergencies would be street lamp poles. In my city, most are metal or composite smooth tapered poles with a height of about 40 feet. If one could deploy a pole climbing vehicle which could drive up the pole with a AREDN device mounted and park, then position the AREDN device in az and alt dimensions, you might have a very good portable operating position. If the pole climbing vehicle had enough torque to haul 50 feet of Cat5e cable plus the payload of a NanoStation, such a device could be powered from the ground by a solar backed battery for long periods.
What I envision is the use a a remote controlled, wheeled design which can encircle and grip the pole as it ascends. Servos as used in RC models could aim the device once the height is achieved and it is steered into place by drive wheels. Another servo might deploy an anchor cam to lock it in place. An Az/El mount would be used to aim a small beam like the NSM5 or NanoBeam M5 for optimum signal.
I imagine that a prototype might be two remote-controlled cars strapped on opposite sides of a pole with a harness, and motors driven together to climb. If you used a Mikrotik LDF5nd as the survey device, the aiming would be less critical due to the wide angle coverage. You would need 12-24V of PoE power locally using a vehicle mounted battery. You would then connect to that survey robot vehicle from your ground position using a similar LDF5 at low power.
Let us know how your project goes!
73,
Brett, KG7GDB
Willamette Valley Mesh Network