Clock Synchronisation

In order for the DroneDeploy Robotics Portal features to operate correctly, it is important that the Agent shares a common understanding of the current date/time with both the DroneDeploy Cloud infrastructure, and the client from where the user is interacting with the robot. This assumption may be challenged if the system clock on the robot, or on the user's computer, is incorrect.

Agent Clock Correction

At startup, the Agent will automatically attempt to use NTP to compare the local system clock with a known good clock source which matches the clocks used by the DroneDeploy Cloud. If the local system clock does not match the reference clock, the Agent will not attempt to correct the local system clock, but instead takes note of the difference, and uses this to correct timestamps reported by the system clock. You can view the current calculated clock offset as the telemetry item /rocos/agent/clock/offset.

The Agent's clock correction is only intended to compensate for small inconsistencies in clock times. If the detected clock offset is more than one second, the Agent will report this as a warning in its startup logs.

If the Agent is not able to obtain a good estimate of the clock offset, or is unable to contact the NTP server, then it will also report an error at startup. In this case, if the local system clock does not match the DroneDeploy Cloud time, then messages may be timestamped incorrectly, and other time related functionalities may not operate as expected - in this situation, any Commands which have been configured to require clock sync will automatically be rejected for safety.

The clock offset is recalculated once every six hours; if the local system clock is changed during this time, the offset will become incorrect, and abnormal behaviour may result. Accordingly, you should not alter the local system clock while the Agent is running (normal NTP system clock adjustment, which happens relatively slowly, is acceptable). If your robot has no RTC, such that the system clock is initially incorrect during startup, and is then adjusted to the correct time during boot by some external source (such as GPS), then you should configure the init system appropriately to ensure that the Agent daemon is not started until after the clock has stabilised.

If necessary, automatic clock correction may be disabled by setting the key disabletimesync to true in the Agent's static configuration file (refer Agent Configuration).

Storage Stream Data

Data collected by a Storage Stream is timestamped upon creation, so that it can be queried for later visualisation. Incorrect time stamping of data may lead to that data not appearing as expected in the Storage Explorer.

For instance, if the local (browser) system clock time is incorrectly set far in the past, then you will not see recent data from your robot when you query for "data from the last 5 minutes", because that data will appear to occur in the future from the perspective of your browser. Similarly, if the robot system clock is set far in the future, and the agent's clock correction has been unable to compensate.

There will be a warning message displaying at the top of the Storage Explorer page if, when performing a query, the query finds any results where the value of the dateCreated property is more than 10 minutes in the future compared against the local system clock time when the storage stream explorer page was loaded.

You may check the property dateCreated visible in the raw JSON view of each Storage Stream message, to see when that data was originally captured by the Agent - this time is calculated by the Agent in combination of the local system clock time, and current agent clock correction offset.