MQTT State vs OSD - Update Rate.
Completed
Changes in mode_code should be pushed when changed. The OSD latency at 2 seconds is insufficient to capture accurate data. It's very easy to miss mode_code changes from 0, 1 & 2 on a fast takeoff which is critical in a public safety environment. Asking first responders to wait before taking off is unacceptable. An MQTT status push using something like the "KeyAreMotorsOn" that could be easily pushed into the Cloud API could help remedy some of this missed data, For instance when a flight is taking off. Updating the OSD rate to 500ms or 1 second would remedy a lot of problems with people trying to integrate. All this is regarding the Pilot 2 Cloud API, not the Dock. According to your docs how could mode_code not fall in a change of state? Why the OSD Topic?
| thing/product/{device_sn}/state | Device > Cloud Server | state message struct | The properties that are uploaded in need by device（properties）, For the specific content range, please refer to the content of the thing model. |
-
At present, we're considering sending the mode_code at a fixed frequency to third-party services to ensure they receive it reliably, in case network issues on their end might cause them to miss collecting the mode_code. There's a potential risk that mode_code updates sent through a 'state' topic could be lost by the third party. -
I've noticed this problem as well. Its not a network problem the update rate is. Fast takeoff's without letting the drone site on the ground and run for a minute will miss mode codes. I feel your pain about the slow update rate. To bad the OSD rate can't be set unlike the dock versions. Missing the boat on this one.
Please sign in to leave a comment.
Comments
5 comments