Glossary

Fictionlab > Glossary > LoRa

LoRa

LoRa – definition

LoRa is a proprietary physical-layer radio modulation developed by Semtech. It uses chirp spread spectrum (CSS) modulation to transmit small data packets, typically over sub-gigahertz unlicensed radio bands. In mobile robotics, LoRa is primarily used as a low-bit-rate communication link for telemetry, remote status reporting, mission commands, and sensor values that do not require real-time delivery.

LoRa is not equivalent to LoRaWAN. LoRa defines the radio modulation and packet transmission capabilities of compatible transceivers. LoRaWAN is a separate low-power wide-area network protocol maintained by the LoRa Alliance. LoRaWAN specifies the MAC layer, device activation, network architecture, and AES-128 security mechanisms; regional channel plans are defined in separate LoRaWAN Regional Parameters documents.

For an unmanned ground vehicle (UGV), LoRa is normally an auxiliary communication channel rather than a transport for navigation, video, LiDAR scans, or high-rate ROS 2 topics. Autonomous navigation, state estimation, obstacle avoidance, and motor control should remain on the onboard compute unit because LoRa links have limited throughput and non-deterministic latency.

How LoRa works on a mobile robot

A LoRa transmitter converts a digital payload into frequency chirps. A chirp changes its frequency over time. The receiver correlates the received chirp pattern with the configured spreading factor and bandwidth. This improves receiver sensitivity compared with conventional narrowband modulation, but reduces usable data rate.

The following radio parameters directly affect link budget, airtime, packet capacity, and latency.

Parameter Typical values Effect on a UGV link Source
Spreading Factor (SF) SF7 to SF12 Higher SF increases sensitivity and airtime. SF12 is more robust but substantially slower than SF7. Semtech AN1200.22
Bandwidth (BW) 125 kHz, 250 kHz, 500 kHz Higher bandwidth can increase data rate but reduces receiver sensitivity. Semtech AN1200.22
Coding Rate (CR) 4/5 to 4/8 More forward error correction improves resilience but increases airtime. Semtech AN1200.22
Transmit power Regional and device dependent Must comply with local spectrum regulations, including equivalent radiated power and duty-cycle limits where applicable. Applicable national and regional radio regulations

LoRa physical-layer data rate is not fixed and depends mainly on SF, BW, and CR. Airtime and effective application throughput also depend on preamble length, payload length, and protocol overhead. A low-rate configuration may provide a longer practical link budget in open terrain, but it can occupy the channel for hundreds of milliseconds or longer. This makes it unsuitable for closed-loop remote driving and emergency-stop functions that require deterministic timing.

LoRa and LoRaWAN in ROS 2 systems

ROS 2 does not define a native LoRa transport. In practice, a LoRa radio is connected through UART, USB, SPI, or a gateway computer. A ROS 2 node serializes selected robot data into compact packets, sends them through the radio interface, and republishes decoded values as ROS messages.

A gateway should publish only information that remains useful at low update rates. Suitable examples include battery state, GNSS position, mission state, environmental measurements, and fault codes.

# Example: publish compact telemetry for a LoRa gateway
ros2 topic pub /lora/telemetry std_msgs/msg/String \
"{data: 'id=leo-01,battery_pct=78,mode=patrol'}"

For production systems, a custom message is preferable to a formatted string. It defines field types explicitly and reduces parsing ambiguity.

# msg/UgvTelemetry.msg
uint32 sequence
builtin_interfaces/Time stamp
float32 battery_voltage
float32 battery_percentage
float64 latitude
float64 longitude
uint8 mission_state
uint16 fault_flags

ROS 2 Quality of Service (QoS) policies apply between DDS participants. They do not guarantee delivery over a LoRa link. A gateway node should therefore add its own sequence number, timeout handling, acknowledgement policy, retransmission limit, and stale-data detection.

Practical integration with Leo Rover and Raph Rover

Leo Rover can run ROS 2 on its onboard Raspberry Pi compute unit. A LoRa modem can be attached through USB, UART, or SPI, depending on the selected radio module and carrier board. The robot can run a gateway node locally while navigation and perception remain onboard.

A practical Leo Rover architecture separates low-bandwidth field telemetry from local autonomy.

  • Onboard ROS 2 stack: wheel odometry, IMU integration, SLAM, Nav2, camera processing, and motor control.
  • LoRa gateway node: periodic transmission of battery level, pose estimate, GNSS data, operating mode, and diagnostic flags.
  • Base-station gateway: packet decoding, logging, operator dashboard integration, and forwarding to a ROS 2 network when available.
  • Fail-safe behavior: autonomous robot behavior must not depend on continuous LoRa connectivity.

Raph Rover can use the same architecture when a larger payload, external battery system, or additional field sensors are required. Its larger platform does not change LoRa bandwidth limitations. It may, however, provide more installation space for an external antenna, weather-resistant enclosure, radio gateway, and dedicated onboard computer.

Suitable and unsuitable ROS data

LoRa is appropriate when the payload is compact and the application tolerates delayed or intermittent packets. Message design should prioritize state changes and summaries over raw sensor streams.

ROS data type LoRa suitability Reason
sensor_msgs/BatteryState Suitable Low update frequency and small payload after selecting required fields and using compact serialization.
sensor_msgs/NavSatFix Suitable Position, fix status, and covariance summary can be transmitted periodically.
diagnostic_msgs/DiagnosticArray Suitable with filtering Transmit selected diagnostic levels and fault identifiers, not complete verbose text.
sensor_msgs/LaserScan Unsuitable Laser scan payloads are too large for practical low-rate LoRa telemetry.
sensor_msgs/Image Unsuitable Image and depth streams require substantially higher throughput.
geometry_msgs/Twist Not recommended for control Packet delay and loss make LoRa unsuitable as the primary motion-control channel.

LoRaWAN considerations for field robotics

LoRaWAN is useful when a UGV reports data through an existing LoRaWAN gateway infrastructure. The LoRaWAN specification defines Classes A, B, and C. Class A is the lowest-power model because downlinks are scheduled after an uplink. This behavior can add command latency and is important when designing remote mission-control workflows.

LoRaWAN uses AES-128 cryptography for network and application-layer protection. Raw LoRa point-to-point communication does not automatically provide equivalent authentication or encryption. A custom raw-LoRa protocol should therefore implement message authentication, replay protection, key management, and payload encryption where required.

Normative references and technical sources

The following documents define the main technical context for LoRa and ROS 2 integration. Regional radio requirements must always be verified for the intended deployment country.

See also