IoT Basics for Robotics: Layers, Radios and Message Design

Think about how milk reaches a dairy in Madhya Pradesh. Hundreds of farmers bring cans to a village collection centre. The centre tests each can for fat content, notes it in a register and pays the farmer. A tanker then carries chilled milk to the plant, and the cooperative's office reads monthly totals to plan prices and routes.

No one carries every cow's milk straight to the head office. Each level does what it is best placed to do, and only what is needed travels further.

An IoT system is built the same way.

What is IoT?

Map the dairy onto IoT. The farmers and their cans are devices: sensors and robots that produce data. The roads and tankers are connectivity. The village collection centre, which tests and summarises before passing anything on, is the edge gateway. The cooperative office is the cloud application where dashboards, storage and planning live.

The Internet of Things (IoT) is a network of physical objects fitted with sensors, processors and communication hardware that collect data about the world and exchange it with other devices and servers, so that the data can be monitored, analysed and acted on automatically.

For robotics, IoT matters in two directions. Robots are producers of IoT data, sending battery, position and health telemetry to a dashboard. And robots are consumers, reacting to fixed sensors, such as a farm robot that heads to the field section where soil moisture has dropped.

The four layers of an IoT system

Data flows up as compact messages; commands and updates flow back down.

1. Device layer. Sensors and actuators with a microcontroller, such as an ESP32 reading a soil probe, or a robot reporting its own state. Devices often run on batteries and sleep most of the time.
2. Connectivity layer. The radio or wire that carries messages: Wi-Fi, Bluetooth Low Energy, LoRaWAN, cellular or Ethernet.
3. Edge or gateway layer. A Raspberry Pi, router or industrial PC that collects messages from many devices, filters them, buffers them when the internet drops and translates between protocols. This is the same "decide close to the data" idea from edge-cloud robotics.
4. Cloud and application layer. Databases for time-series data, dashboards, alerts, analytics and device management, including over-the-air (OTA) firmware updates.

Which wireless technology should an IoT device use?

There is no single best radio. Each trades range, data rate and power against one another.

Move right for range, up for data rate; power use generally rises with data rate.

A rule of thumb: use Wi-Fi when you have power and a building network, LoRaWAN when you have no network and send a few bytes, and cellular IoT when devices move around a city or region.

Application protocols

The radio moves bits; an application protocol gives them meaning. HTTP is simple and universal but heavy for tiny devices.

MQTT is a lightweight publish/subscribe protocol and the most common choice for IoT telemetry; the next article, MQTT protocol explained, covers it in depth. CoAP is a compact, HTTP-like protocol over UDP for very constrained devices, and WebSockets suit live browser dashboards.

Designing IoT messages: small and only when needed

Battery life and data bills are decided by how many bytes you send and how often. Start with the message format. The JSON in this example is readable but repeats every key name in every message; a packed binary layout sends only the numbers.

import json, struct
# One reading from a farm robot's sensor pod
reading = {"id": "rover-07", "ts": 1794211200, "soil_moisture": 31.4,
           "temp_c": 29.8, "battery_v": 7.62, "lat": 22.7196, "lon": 75.8577}

as_json = json.dumps(reading).encode()
compact = json.dumps(reading, separators=(",", ":")).encode()
# Binary: 2-byte robot number, 4-byte time, then scaled integers
binary = struct.pack("<HIHhHii", 7, reading["ts"], int(reading["soil_moisture"] * 10),
                     int(reading["temp_c"] * 10), int(reading["battery_v"] * 100),
                     int(reading["lat"] * 1e6), int(reading["lon"] * 1e6))

per_month = 6 * 60 * 24 * 30            # one reading every 10 s
for name, payload in [("pretty JSON", as_json), ("compact JSON", compact),
                      ("packed binary", binary)]:
    mb = len(payload) * per_month / 1e6
    print(f"{name:14s} {len(payload):4d} bytes  -> {mb:6.2f} MB per month per device")

robot, ts, soil, temp, batt, lat, lon = struct.unpack("<HIHhHii", binary)
print("decoded:", robot, ts, soil / 10, temp / 10, batt / 100, lat / 1e6, lon / 1e6)

Binary is six times smaller, which matters on LoRaWAN, where a payload may be limited to a few dozen bytes. JSON is easier to debug and evolve. Many teams use compact JSON over Wi-Fi and binary over LoRaWAN or cellular, with the gateway decoding binary into JSON for the cloud.

Report by exception

The second lever is frequency. Instead of sending every sample, a device can send only when the value changes by more than a deadband, plus a regular heartbeat so the server knows the device is alive.

import numpy as np
rng = np.random.default_rng(4)
# 24 hours of temperature sampled every 10 s: slow daily swing plus sensor noise
t = np.arange(0, 24 * 3600, 10)
temp = 27 + 6 * np.sin(2 * np.pi * (t / 86400 - 0.3)) + rng.normal(0, 0.08, t.size)

def report_by_exception(values, deadband, heartbeat_s=900):
    sent, last_val, last_t = [], None, -heartbeat_s
    for i, v in enumerate(values):
        now = t[i]
        if last_val is None or abs(v - last_val) >= deadband or now - last_t >= heartbeat_s:
            sent.append((now, v)); last_val, last_t = v, now
    return sent

print(f"send every sample: {t.size} messages per day")
for band in (0.1, 0.25, 0.5):
    sent = report_by_exception(temp, band)
    times, vals = np.array(sent).T                  # the server holds the last value
    held = vals[np.searchsorted(times, t, side="right") - 1]
    print(f"deadband {band:4.2f} C: {len(sent):5d} messages "
          f"({len(sent) / t.size:5.1%}), worst error {np.abs(held - temp).max():.2f} C")

A 0.25 °C deadband sends 4% of the messages while the server's copy is never more than 0.25 °C wrong. Notice the 0.10 °C case: the deadband is close to the sensor noise, so noise alone triggers more than a third of the messages.

Set the deadband above the noise level, or filter first. If you need a refresher on the loop and condition logic, see Python for loops and if-else.

An ESP32 node that wakes, measures, reports and sleeps

Here is the device side of the pattern on an ESP32 with the Arduino core. It keeps the last reported value in RTC memory, which survives deep sleep, and only turns on Wi-Fi when the change exceeds the deadband or the heartbeat is due.

#include <WiFi.h>
#include <HTTPClient.h>

RTC_DATA_ATTR float lastSent = -1000;      // survives deep sleep
RTC_DATA_ATTR int wakesSinceSend = 0;
const float DEADBAND = 0.25;
const int HEARTBEAT_WAKES = 90;            // 90 x 10 s = 15 minutes
const uint64_t SLEEP_US = 10ULL * 1000000ULL;

float readSoilMoisture() {
  return analogRead(34) * 100.0 / 4095.0;  // replace with your calibration
}

void setup() {
  float value = readSoilMoisture();
  wakesSinceSend++;
  if (fabs(value - lastSent) >= DEADBAND || wakesSinceSend >= HEARTBEAT_WAKES) {
    WiFi.begin("farm-gateway", "your-password");
    for (int i = 0; i < 50 && WiFi.status() != WL_CONNECTED; i++) delay(100);
    if (WiFi.status() == WL_CONNECTED) {
      HTTPClient http;
      http.begin("http://192.168.1.10:8080/telemetry");   // the edge gateway
      http.addHeader("Content-Type", "application/json");
      String body = "{\"id\":\"node-03\",\"soil\":" + String(value, 1) + "}";
      if (http.POST(body) == 200) { lastSent = value; wakesSinceSend = 0; }
      http.end();
    }
  }
  esp_sleep_enable_timer_wakeup(SLEEP_US);
  esp_deep_sleep_start();                  // setup() runs again after waking
}

void loop() {}

For production, swap plain HTTP for MQTT over TLS and give each node its own credentials. The radio and Wi-Fi setup are the same as in the ESP32 Wi-Fi robot project.

IoT security and device management basics

IoT devices sit in fields, factories and homes for years, often unattended, so plan security from day one:

• Unique identity per device. No shared passwords baked into every unit.
• Encrypt in transit with TLS, and do not leave brokers or dashboards open to the internet without authentication.
• Signed OTA updates, so you can fix bugs remotely without letting anyone else push firmware.
• Least privilege. A soil node should be allowed to publish its readings, not control the irrigation pump.
• Watch the fleet. Track last-seen time, battery and firmware version for every device.

Common IoT mistakes

• Sending everything, always. Report by exception and summarise at the gateway.
• No offline buffer. When the internet drops, the gateway should store messages and forward them later.
• Ignoring time. Without synchronised clocks (for example via NTP), readings from different devices cannot be compared.
• Testing range on the bench. Walls, crops and metal racks shrink real range dramatically.

Key takeaways

• IoT connects sensors and robots to each other and to applications through four layers: device, connectivity, edge gateway and cloud.
• Choose the radio by range, data rate and power; there is no universal best.
• MQTT is the usual application protocol for telemetry; HTTP, CoAP and WebSockets have their places.
• Small payloads and report-by-exception decide battery life and data cost.
• Unique identities, TLS and signed updates are basic IoT hygiene.