I am currently working on a Raspberry Pi based robotics project that I would like to connect to a realtime customized control panel/dashboard, mostly for debugging purposes. I created a test setup where each instance of the robot "operating system" can be seen as a separate device in the dashboard, with a unique session and device ID associated to each. In theory you can connect multiple robots to the same dashboard and see what they are up to in realtime.
To summarize the setup:
- The robot itself runs on a mix of C++ and Python (Raspberry Pi + ESP32)
- The dashboard server runs on NodeJS, and takes care of connecting to the robot, and forwarding data to the dashboard client
- The dashboard client is available from the server and receives realtime updates every 10ms via an UDP socket
Currently the robot will broadcast an UDP message on the local network every minute, so that it can be discovered by the dashboard server. Once the dashboard server notices one of these "pings" it will send out connection information to the robot (e.g. port to send the realtime data to). When the robot and dashboard server are connected, the robot will send out a serialized version of all relevant internal data/variables every 10 milliseconds. Think of information like motor position, speed, camera input, obstacles etc.
This method of connecting seems to work fine for now, but I was wondering if there is a better/more mature way of making the robot announce itself to the local network, and then connecting to one or more dashboard instances. I read about SSDP (as part of UPnP) as a good but also dangerous way of making devices announce themself to a network. Would it be recommended and common practice to use SSDP for this case, or are there better alternatives that are more futureproof (also security wise)? The robot can be considered an IoT device, but from the different online sources that I have read so far, IoT devices using UPnP and SSDP are considered a security risk that many end users are not aware of. Is this truly the case?