OpenRoberta
update robot protocol
The improvements need a clear concept before starting implementing.
The push protocol is necessary to handle restricted network setups. It comes with limitations (bandwidth and latency) and overhead though. A websocket won't have these limitations, but might not work in all cases.
- [ ] prefer websocket with push protocol fallback
- [ ] send connected peripherals with each push (or heartbeat in the case of websockets), sensors or encoder will contain their mode and value as well
- [ ] publish new endpoint under versioned urls. this allows us to keep older version alive for some time
In general we should take care of backwards compatiblility and also we should make clear for further robot/system integrations, that there is a small and basic protocoll which each robot/system or usb program should support. Specific addons can only be implemented when we have a reliable testscenario for the basic protocoll to garantie backwards compatibility.
I think this is relevant for this issue, namely updating the protocol. In usb program there is a field missing, namely robotGroup. Because currently we have robot, which is robot's name like "botnroll" for example and we have brickname, which is unique name of the robot like "myBnROne" so there should be also a robotGroup variable to be set to "ardu". Currently web-gui when selecting a robot sets robotName and robotGroup. Overall this led to a confusion and a bug that does not allow usage of USB program v2.0.4 with latest develop
Just to make sure, the robotGroup from the GUI is only for robots that have the exact same blocks. Nothing more. I think it is not a good idea to use this group on serverside.
For the fields discussion, I would prefer a new bug. This bug should list what data we send for which robots connection helpers and how it is used. We can edit the bug post as we collect the data.
for the txt4 controller plugin we revised the protocol and documented it in the Github wiki. It supports everything we currently require. We close the ticket, even if a complete redesign of the whole robot-server communication makes sense, but we don't have the time to work on that.
