이전 노션 블로그의 LoRa Network performance enhancement (2023.03.26)로부터 마이그레이션된 글입니다.
This is a post about my project from K-SW Purdue program. The project was Power Efficient Long Range Drone Networking System for UAV Dection
, the solution to make a drone detect other drones. This is a abstract section written in a paper.
Abstract—In recent years, technological advancements in Unmanned Aerial Vehicles (UAV) have removed barriers to entry on drone usage for the public. While this has led to the growth of the drone industry it has also provided terrorists with easier access to drones. Rising threats of malicious drones have raised the importance of a Counter Drone System (CDS). Traditional CDSs use a variety of physical sensors and technologies to detect hostile drones and react efficiently, however, these methods have their own set of constraints, such as high power consumption and short operational range. This paper proposes a power-efficient long range CDS composed of a LoRa mesh network and ondevice Machine Learning (ML). LoRa provides low-power and long range communication and the multi-hop feature of the mesh network expands the coverage of the network. Applying Tiny Machine Learning (TinyML) for detecting drone on the MicroController unit is reasonable to design long range communication. On device Machine Learning has no round trip between server
and device. The implemented system achieves a satisfactory communication range, a successful operation of the UAV detection and a power consumption which is similar to that of typical MCU.
First demo was successfully developed, so it was in the stage of an field experiment. Key points of first experiment was estimating a network quality. It would be evaluated by the maximum communication distance. However we could not measure the distance until network is disconnected since the communication distance of LoRa is basically in kilometers.
Therefore we calculated the max communication distance like this.
1st measurement | 2nd measurement |
---|---|
Device | Device attached to drone | Test field |
---|---|---|
Experiment was consist of one Ground node(Node 1) and UAV nodes(Node 2, 3). The reasons for configuring the environment this way will not be covered here. The communication between Node 2 and 3 will be covered due to this post is written to record what and how i try to enhance the max communication distance.
Unfortunately, the measurement result was too bad. Network couldn’t work at the distance longer than 10 m. This was totally different with what we estimated.
This research show LoRa network devices communicate far from 10 km. Although it was conducted with high performance devices like more expensive board and longer antenna, 10 m was too short. Our networking was not even affected by Fresnel zone due to networking is constructed high enough in the air. We started looking for the cause of this bad result.
The first things suspected was the hardware. We bought each hardwares and i soldered myself to optimize energy consumption. because every Micro board that had LoRa transceiver and camera both on sales had a LED monitor also. However we don’t need the monitor. Monitor will consume high energy. Even if the monitor is turned off, the weight of monitor increases the drone’s energy consumption.
Soldering was not easy, and the most difficult part was that red rectangle part in Fig 2. Antenna SMA adapter had 5 pins in small area, so some boards soldering was too big. It seemed like each pin’s soldering were almost touching each other. Prof. Matson also advised that these soldering may interrupt other pins’s electric signals.
However, there was no time to order new parts. The deadline was right around the corner. I melted old soldering by lowest temperature not to damage the LoRa transceiver and stripped off.
There was a quite small improvement. Only 1 m ~ 2 m communication distance was extended. Main cause of bad result was not this.
I noticed something odd while analyzing the logs of first experiment. Although i set logging delay as 500 ms, log was recorded every 500 ms ~ 1500ms. I followed up all networking and logging functions again, but there was wrongly written code or configuration. So i read up networking library documents and library code also, and finally I found a suspicious function.
The device use doArp()
to check RSSI with all others devices, because transceiver need to communicate with other device at least once time to know RSSI. However in order to use sendToWait()
function (normal transmit function), we must send any char array. so doArp()
function, whose purpose is to find the route to other device, seemed very suitable only for checking RSSI
The problem was a principle of Mesh network. A mesh network can transmit data to a device far away via a nearby devices. In order to transmit data via relaying, mesh network start to find the route to destination by broadcast. Departure device transmit the broadcast signals to all others devices and nearby devices that received signal also transmit the broadcast signals to all others. As a rusult, the route is composed of the most optimal paths.
The purpose of doArp()
function is resolving a route, so whenever doArp()
function is executed, broadcast communication is also transmitted. Our devices call this every 500 ms and there was 3 devices Therefore, Broadcast storm has occurred and broadcast storm interrupted communication.
I refactored the log function. (📬 Commit link). I used sendToWait()
, instead of doArp()
.
The devices was able to communicate successfully even at the distance as long as possible indoors.
Log of indoor test. Log is consist of (Stopover node to go node N, RSSI with stopover node)
We conducted second experiment and got good measurement. The calculation for the maximum communication distance was based on measurement. As a result of, the maximum communication distance was 1044m. Improved 10 m to 1044 m, 100.09%
Broadcast storm was real cause of bad result. Experience of this troubleshooting was so stressful but impressed. It was very new that low level network, not the code, was the cause of the problem and the debugging experience that read low level network up took me to new level.