Add timestamps to variables

[Affie]

Timestamps are just as important as position and orientation and should be quickly accessible and searchable.
xref #268

[dehann]

Hi, the initial thinking was that new data (which may vary from application to application) be added to small data. If there is something repeatable, then maybe the data should be moved to softtypes as a kind of metadata. Turns out that we may have to do a review of what the fundamental data types are going forward.

Is there a specific type of timestamp,

• Sensor time
• Computer version of data acquisition time, (may this is the one you're)
• Data communicated time,
• Database created time?

Also, the thinking is to standardize around microsecond time for sensors, and some UTC time for other epoch events.

[GearsAD]

I would suggest acquisition time, we have DB time already. It would be the UTC timestamp of the pose.

[dehann]

also see JuliaRobotics/RoME.jl#62

[dehann]

For accurate navigation we would likely need sensor time and "computer received time" be kept separate. The most likely usage is "computer acquisition/received time", with the assumed accuracy of tens of milliseconds from actual sensing event.

[jim-hill-r]

In my experience in IIOT, there are always three times recorded:

1. Event time: When the actual thing happened (as accurately as possible based on DAQ latency and corrections)
2. Received time: This is when whatever system that wants to process the event or measurement gets it. This is critical in store and forward or loss of connectivity contexts. There may be many of these if many systems are involved.
3. Last Updated time: This is the database time. When was it last persisted/saved. The difference between 3 and 2 is how long it takes to process which could be important. This also represents when consumers start to see the change. Again, there may be many if there are many databases involved.

[dehann]

Cool, so how about this:

0. Use the names:
   -- 'sensor's event time' [microseconds];
   -- 'first received epoch' [UTC, GMT + 00];
   -- 'db/last _updated time' [UTC, GMT + 00];

1. We store all these timestamps in the same place, probably in smalldata for now:
   -- We start by definitely not storing the timestamps in VariableNodeData -- especially since they are subject to change;
   -- Softtype-metadata is maybe an option, however, we would have to add timestamp fields to all softtypes but timestamps are more general than that.

2. A "special operation" is performed where the first received epoch---when storing to DB---is escalated to node property level (similar to n.MAP_est), in the most user friendly / cypher searchable format, thereby allowing space and time foveation queries.

[dehann]

Being done as part of the DFG upgrade, see IIF v0.7 (tentative merging version for DFG).

[dehann]

see here:
https://github.com/JuliaRobotics/DistributedFactorGraphs.jl/blob/fcd5247a73b5432543afb63b9d567cb03edfc31f/src/entities/DFGVariable.jl#L51

[dehann]

done