communication between payload and command station is critical when dealing with a fire scene. Our project finds itself between two challenges: Firefighters need reliable communication networks, but transmitting SLAM data will require more bandwidth. Increasing data bandwidth often leads to making sacrifices to reliability by increasing transmission frequency or distributing the power over a wider range of frequency, both of which make the system more susceptible to noise.
915MHz vs. 2.4GHz Tests
The first step in our comms journey began with a MATLAB simulation to evaluate if the 915MHz frequency range would be able to transmit more reliably than at the 2.4GHz range. This simulator used the QPSK modulation scheme, simulated a 50ft channel in 1000 degrees celcius temperature through five 6″ concrete walls. This extreme environment resulted in only a 4.82 percent error in QPSK symbol location (anything below 12.5 percent is ideal). The results of this sim built confidence in purchasing the Haltec 915MHz radio for a physical performance test.
Physical tests were conducted using two different types of radios: A pair of 2.4GHz Doodle Radios and a router/bridge pair of 915MHz. The command station was at the central pavilion, and the radio was taken into buildings A, B, and C. We then tested both the bandwidth (Mbps) and the packet loss (out of 10000 packets). Robert controlled the command station at the pavilion, while Joy went to the test points in each building.
The result of this test is clear: The 915MHz radios are incredible effective, and blow the performance of the doodle radios out of the water in the challenging environments of concrete and metal. It was a resounding success of a test. Average transmission was 15Mbps. The lowest transmission was 5.59Mbps, but this is still 3 times our 2Mbps target!
Heltec Radio Configuration
The Heltec radios purchased are as follows:
- One Heltec HaLow Router configured as Access Point
- Two Heltec HaLow Dongles configured as bridges
The dongles will go onto the payloads, while the router will interface with the command station laptop. The connection between the router and the dongles is predefined, allowing them to automatically establish a link once powered on.
Data flows from the payload to the dongle, then over the HaLow link to the router, and finally to the command station. The screenshot shows the GUI used to configure the HaLow dongles as bridges.
ROS2 Communication Middleware Selection
To support scalable C-SLAM, it is important to reduce unnecessary network traffic, especially in multi-agent scenarios.
In ROS2 DDS, multicast is used for topic discovery and communication. This means data and discovery messages are broadcast to all nodes on the network, regardless of whether they are needed.
In contrast, unicast communication sends data only to specific endpoints. This reduces unnecessary traffic and provides more efficient communication, making it more scalable.
However, when transmitting large data streams, such as thermal images, the benefit of eliminating discovery overhead becomes less, as the data itself dominates the bandwidth usage.
Both the command station and the payload publish many ROS topics. With multicast-based discovery, all topics are broadcast across the network, which can create excessive discovery traffic and jam the network at startup, especially when running SLAM or visualization tools such as Foxglove.
To address this, we use CycloneDDS together with the Zenoh bridge to enable controlled unicast communication. CycloneDDS serves as the ROS2 middleware, while the Zenoh bridge routes DDS traffic and allows us to block unnecessary topics using an allow list. This ensures that only selected topics are transmitted over the HaLow link, while all other topics remain local.
The results, measured at the command station, show that outgoing traffic is reduced to nearly zero, while incoming traffic is significantly reduced.
Key Advantages of Zenoh bridge + CycloneDDS
- No unnecessary discovery traffic
- Block unwanted topics (allow list)
- Improves communication efficiency and scalability for C-SLAM
