use ApproxManiProds.skew instead #747
Conversation
| @@ -340,6 +326,9 @@ end | |||
| IIF.getManifold(::IMUDeltaFactor) = IMUDeltaGroup() | |||
|
|
|||
| function IIF.preambleCache(fg::AbstractDFG, vars::AbstractVector{<:DFGVariable}, ::IMUDeltaFactor) | |||
| # FIXME, nsec should only contain fractional second information, i.e. < 1.0s. Use together with `trunc(timestamp) + 1e-9*nsec` | |||
There was a problem hiding this comment.
That is not how I use it and not how its documented.
There was a problem hiding this comment.
Again, we should do what ROS does and not our own special thing. By the way, the suggested code here works for both cases. We should also update our documentation to reflect the same as ROS.
There was a problem hiding this comment.
We had this discussion before and also didn't agree then.
If you want to do what ros does:
Split the timestamp in two 32 bit timestamps, one for your ns and the other for the second part. The 2 combined as a single 64bit timestamp is basically what you have here.
By the way, the suggested code here works for both cases. We should also update our documentation to reflect the same as ROS.
I feel like a parrot, but it doesn't, I've had multiple cases where there are 2 different timestamps. Not all timestamps are synced, and not all timestamps are unix epoch.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
There was a problem hiding this comment.
There was a problem hiding this comment.
I feel like a parrot, but it doesn't, I've had multiple cases where there are 2 different timestamps. Not all timestamps are synced, and not all timestamps are unix epoch.
So what I'm looking to get right here is that this should never be allowed to happen. Sounds like imposing a restriction (along with .missionnanosec) would be the only way to avoid this?
Synchronization may well be a session-delta (or clone of session to resolve). Ultimately the unsync'd graph variables (or whole graph fragment) should be replaced so that only consistent timestamps remain. We should not kick the can down and have users struggle with timestamps downstream.
There was a problem hiding this comment.
32 bit timestamps
I mean that we stay with 64 bit (obviously).
Note some web stacks only support 32 bit at this time. Some of the json libraries was the example we bumped into before. In that case we should then still be good, but would not be our "fault" if it happens somewhere.
There was a problem hiding this comment.
updated the FIXME comment to be inline with missionnanosec.
waiting on: