CAUSE V: Testing Telecommunications Coverage and Bandwidth for small UAS

CAUSE V: Testing Telecommunications Coverage and Bandwidth for small UAS

Posted by admin on Dec 26, 2017 at 9:25 am America/Chicago

In November, members of the Roboticists Without Borders small UAS and UMV teams participated in CAUSE V, a joint US-Canada DHS exercise focusing on wireless communications during a disaster. Check out the fantastic article by Jim Moore, one of our newest RWB members, at: https://www.aopa.org/news-and-media/all-news/2017/december/11/the-art-of-disaster-response-by-drone

CAUSE V is a good example of the telecommunications challenges in exploiting unmanned systems during emergencies. CRASAR has been working with Dr. Walt Magnussen and the Internet2 Technology Evaluation Center through the Winter Institute series and I’ve presented to the President's National Security Telecommunications Advisory Committee in 2016.  At CAUSE V, we encountered that same telecommunications problems that I’ve seen since the early 2000’s (and continue to present on).  Two challenges- that network coverage doesn’t match the area of operations and there is insufficient bandwidth— are detailed below in the hopes of providing more clarity.

One, Coverage of the emergency wireless networks did not match the actual area of small UAS operations and would not have covered the areas of operations seen in our previous disasters. 

There seems to be an assumption that each UAS team will drive around in a command vehicle and operate from a fixed location. In reality, a group such as ours may have a command vehicle that would serve as forward operating base but individual teams might be embedded with an agency and their vehicles or drive SUVs. The CAUSE V team installed a connection to the emergency network in our mobile lab and provided us with a wireless “bubble” around our mobile lab of about 500 feet.

A UAS team ranges far from the forward operating base and is constantly on the move (and ideally there are many teams). At the CAUSE V exercise, we had 3 teams in the field at any given time and they were between 29-40 miles away from the mobile lab.  At Hurricane Harvey, CRASAR had between 2 and 6 teams in the field at any given time and they were operating between 2 and 45 miles from the nearest base of operations. The time at a location for the the CAUSE V missions and most missions at Harvey was on the order of 16 minutes or less- reinforcing that the teams are highly mobile.

Two, Bandwidth was not sufficient for real-time streaming from one or more UAS, sharing high resolution imagery and video, or uploading imagery for post-processing in the cloud.

Every disaster is different but in general I witness that the immediate response phase of disaster (usually the first 24-48 hours) is characterized by responders and emergency managers seeking immediate situation awareness. The longer they have to defer decisions about life-saving and about what resources to call in, the slower the response and the more shortages in food, water, power, etc. for the citizens because of latency in ordering.

During the immediate response phase, the small UAS provide bursts of:
  • low resolution streaming video. Responders need to see (and direct) what the UAS is seeing in real-time. Since every disaster is different, what they need to see isn’t predictable, so if the UAS team flies but doesn’t capture all the data or from the wrong angle- the team will have to return to re-fly because they will have been done in 20 minutes and moved to the next site which might be 20 miles away. Even a 15 minute latency in streaming can result in hours and hours of delays in re-flying and ultimate decision making. And add months to recovery (if you believe in the Haas, Kates, and Bowden model).
  • high resolution imagery and video. Low resolution is low resolution, you can’t see everything that’s there. As a result, responders such as structural experts will want to go over the individual high rez images and video that are stored on SD cards. But that imagery needs to get to them fast enough from them analyze it and make decisions or recommendations for the next operational period which is roughly every 12 hours. Without higher bandwidth, the current options are for each team to travel back to the forward operating base (which may be 20 miles away but make take 3 hours to drive due to road closures, detours, etc.) or to have a courier adding more manpower. At Texas A&M, we are working on software to snippet and prioritize data to be transmitted but all of work domain analyses suggest that there will still be A LOT of data to transmit. ASAP. Not tomorrow or 3 days from now, which one telecoms person suggested saying that 3 days to get that high res data would be ok, right? No, it's not OK.

Note that mapping and photogrammetric post-processing may not be involved in the immediate response phase for all types of disasters- and looking over our deployments as well as those of other agencies, we are seeing that it rarely is requested or is of value in the immediate response phase. At Harvey, the emergency management agencies wanted solely FPV for the first few days and then shifted to mapping as operations on 9/2/2107 shifted to mitigation and restoration of services (which generally starts about 48-72 days after the event, which may be where the “they don’t need the higher resolution data for 3 days” came from).

But in CAUSE V, a volcanic explosion with a lahar flowing down the mountain, volumetric data from imagery would be extremely important to have as fast as possible and ideally calculated within at least one 12 hour planning cycle. This means driving to the site, flying, driving back, uploading 200-800 high resolution images (from a SINGLE flight) to the cloud, and then downloading the final product- a file somewhere between 0.5 and 3 GB (not the most convenient size to email or share)- in less than 12 hours. One of our mapping flights from Harvey took 17 hours to upload- and we were in the metro-Houston area that hadn’t lost cellular infrastructure!

One solution is for the UAS team is edge computing- to process this in the field or at the forward operating base- assuming that they can afford the software license and the high end computer. We believe that less emphasis should be on the Cloud and more work needs to be into edge computing, where more computation is done onboard the UAS or controller and is done more “invisibly” to the UAS team who don’t have time and cognitive resources to expend.

Regardless, telecommunications continues to be an important key in effective unmanned aerial SYSTEMS.  And many thanks to the organizers who are pro-actively trying to learn how to make telecommunications and FirstNet work for the good of us all!

Tags

Archives

Our Sponsors

© Copyright 2018 Center for Robot-Assisted Search and Rescue

Terms & Conditions | Privacy Policy | Site Map