screwy time stamps when collecting at 200Hz with the VN 100

Question

screwy time stamps when collecting at 200Hz with the VN 100

Closed this issue 3 years ago · 4 comments

I finally got the VN100 to produce data at 200Hz but the time stamps look really weird. The data comes in at 200Hz, but it comes in at irregular times, typically one at close to 10ms time delay, then the next one right away such that the average is about 5ms. Any idea what's going on?
This is using the ROS2 version of the driver. The time stamps are from header.stamp (which agrees reasonably well with the recording time in the bag).

Data layout: timestamp, delta_t

0.007156612396240547 0.009268045425415039 
0.007577421188354805 0.0004208087921142578
0.016905071258545235 0.00932765007019043
0.017284633636474922 0.0003795623779296875
0.024430753707886055 0.007146120071411133
0.034222366333008125 0.00979161262512207

Here is the config file for the VN100:

vectornav:
  ros__parameters:
    port: "/dev/ttyUSB0"
    baud: 921600
    reconnect_ms: 500
    # Reference vnproglib-1.2.0.0 headers for enum definitions
    # Async Output Type (ASCII)
    AsyncDataOutputType: 0           # VNOFF
    # Async output Frequency (Hz)
    AsyncDataOutputFrequency: 200
    # Sync control
    syncInMode: 3                    # SYNCINMODE_COUNT
    syncInEdge: 0                    # SYNCINEDGE_RISING
    syncInSkipFactor: 0
    syncOutMode: 0                   # SYNCOUTMODE_NONE
    syncOutPolarity: 0               # SYNCOUTPOLARITY_NEGATIVE
    syncOutSkipFactor: 0
    syncOutPulseWidth_ns: 100000000
    # Communication protocol control
    serialCount: 0                   # COUNTMODE_NONE
    serialStatus: 0                  # STATUSMODE_OFF
    spiCount: 0                      # COUNTMODE_NONE
    spiStatus: 0                     # STATUSMODE_OFF
    serialChecksum: 1                # CHECKSUMMODE_CHECKSUM
    spiChecksum: 0                   # CHECKSUMMODE_OFF
    errorMode: 1                     # ERRORMODE_SEND
    # Binary output register 1
    BO1:
      asyncMode: 1                   # (just send on port 1, not both!)
      rateDivisor: 4                 # 200 Hz
      commonField: 0x7FFF
      timeField: 0x0000              # TIMEGROUP_NONE
      imuField: 0x0000               # IMUGROUP_NONE
      # set gpsField directly in source to enforce or condition
      attitudeField: 0x0000          # ATTITUDEGROUP_NONE
      # set insField directly in source to enforce or condition
      gps2Field: 0x0000              # GPSGROUP_NONE
    # Binary output register 2
    BO2:
      asyncMode: 0                   # ASYNCMODE_NONE
      rateDivisor: 0
      commonField: 0x0000            # COMMONGROUP_NONE
      timeField: 0x0000              # TIMEGROUP_NONE
      imuField: 0x0000               # IMUGROUP_NONE
      gpsField: 0x0000               # GPSGROUP_NONE
      attitudeField: 0x0000          # ATTITUDEGROUP_NONE
      insField: 0x0000               # INSGROUP_NONE
      gps2Field: 0x0000              # GPSGROUP_NONE
    # Binary output register 3
   BO3:
      asyncMode: 0                   # ASYNCMODE_NONE
      rateDivisor: 0
      commonField: 0x0000            # COMMONGROUP_NONE
      timeField: 0x0000              # TIMEGROUP_NONE
      imuField: 0x0000               # IMUGROUP_NONE
      gpsField: 0x0000               # GPSGROUP_NONE
      attitudeField: 0x0000          # ATTITUDEGROUP_NONE
      insField: 0x0000               # INSGROUP_NONE
      gps2Field: 0x0000              # GPSGROUP_NONE
    frame_id: "vectornav"

vn_sensor_msgs:
  ros__parameters:
    orientation_covariance: [0.01,  0.0,   0.0,
                            0.0,   0.01,  0.0,
                            0.0,   0.0,   0.01]
    angular_velocity_covariance: [0.01,  0.0,   0.0,
                         0.0,   0.01,  0.0,
                         0.0,   0.0,   0.01]
    linear_acceleration_covariance: [0.01,  0.0,   0.0,
                         0.0,   0.01,  0.0,
                         0.0,   0.0,   0.01]
    magnetic_covariance: [0.01,  0.0,   0.0,
                         0.0,   0.01,  0.0,
                         0.0,   0.0,   0.01]

Answer 1 · 2021-12-26T03:39:38.000Z

Without actually looking at it in detail, this is likely a side effect of using USB for high frequency data. The USB protocol is non-deterministic and buffered. This means that while the sensor is accurately collecting data at 200 Hz with regular intervals, that data is buffered and then pulled from the host periodically at a lower frequency. Here are a couple of ideas on how to work around the problem: * The messages also have an internal timestamp from the sensor, this will be the most accurate timestamp. You can use that time system instead of the Ros time, or you can cook an offset between the internal sensor clock and Ros time and sort of correct it back to UTC...(If you are a post-processing the data, like offline slam optimization or something, this is a great way to go) * If you want the most accurate and reliable message. delivery, You would have to use a real UART, and not a USB connection. This would be a much more deterministic way of getting data from the sensor. (If you're performing high frequency closed loop control of some mechanism, like a multirotor UAV, or something like that, this is the way to go) Good luck and let everyone know how you go :)

…

On Sat, Dec 25, 2021, 21:29 Bernd Pfrommer ***@***.***> wrote: I finally got the VN100 to produce data at 200Hz but the time stamps look really weird. The data comes in at 200Hz, but it comes in at irregular times, typically one at close to 10ms time delay, then the next one right away such that the average is about 5ms. Any idea what's going on? This is using the ROS2 version of the driver. The time stamps are from header.stamp (which agrees reasonably well with the recording time in the bag). Data layout: timestamp, delta_t 0.007156612396240547 0.009268045425415039 0.007577421188354805 0.0004208087921142578 0.016905071258545235 0.00932765007019043 0.017284633636474922 0.0003795623779296875 0.024430753707886055 0.007146120071411133 0.034222366333008125 0.00979161262512207 Here is the config file for the VN100: vectornav: ros__parameters: port: "/dev/ttyUSB0" baud: 921600 reconnect_ms: 500 # Reference vnproglib-1.2.0.0 headers for enum definitions # Async Output Type (ASCII) AsyncDataOutputType: 0 # VNOFF # Async output Frequency (Hz) AsyncDataOutputFrequency: 200 # Sync control syncInMode: 3 # SYNCINMODE_COUNT syncInEdge: 0 # SYNCINEDGE_RISING syncInSkipFactor: 0 syncOutMode: 0 # SYNCOUTMODE_NONE syncOutPolarity: 0 # SYNCOUTPOLARITY_NEGATIVE syncOutSkipFactor: 0 syncOutPulseWidth_ns: 100000000 # Communication protocol control serialCount: 0 # COUNTMODE_NONE serialStatus: 0 # STATUSMODE_OFF spiCount: 0 # COUNTMODE_NONE spiStatus: 0 # STATUSMODE_OFF serialChecksum: 1 # CHECKSUMMODE_CHECKSUM spiChecksum: 0 # CHECKSUMMODE_OFF errorMode: 1 # ERRORMODE_SEND # Binary output register 1 BO1: asyncMode: 1 # (just send on port 1, not both!) rateDivisor: 4 # 200 Hz commonField: 0x7FFF timeField: 0x0000 # TIMEGROUP_NONE imuField: 0x0000 # IMUGROUP_NONE # set gpsField directly in source to enforce or condition attitudeField: 0x0000 # ATTITUDEGROUP_NONE # set insField directly in source to enforce or condition gps2Field: 0x0000 # GPSGROUP_NONE # Binary output register 2 BO2: asyncMode: 0 # ASYNCMODE_NONE rateDivisor: 0 commonField: 0x0000 # COMMONGROUP_NONE timeField: 0x0000 # TIMEGROUP_NONE imuField: 0x0000 # IMUGROUP_NONE gpsField: 0x0000 # GPSGROUP_NONE attitudeField: 0x0000 # ATTITUDEGROUP_NONE insField: 0x0000 # INSGROUP_NONE gps2Field: 0x0000 # GPSGROUP_NONE # Binary output register 3 BO3: asyncMode: 0 # ASYNCMODE_NONE rateDivisor: 0 commonField: 0x0000 # COMMONGROUP_NONE timeField: 0x0000 # TIMEGROUP_NONE imuField: 0x0000 # IMUGROUP_NONE gpsField: 0x0000 # GPSGROUP_NONE attitudeField: 0x0000 # ATTITUDEGROUP_NONE insField: 0x0000 # INSGROUP_NONE gps2Field: 0x0000 # GPSGROUP_NONE frame_id: "vectornav" vn_sensor_msgs: ros__parameters: orientation_covariance: [0.01, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.01] angular_velocity_covariance: [0.01, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.01] linear_acceleration_covariance: [0.01, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.01] magnetic_covariance: [0.01, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.01] — Reply to this email directly, view it on GitHub <#87>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHVFZPA2LUBXFUQ6LNIOLUSZ4YDANCNFSM5KYNAVMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 2 · 2021-12-27T21:56:28.000Z

So indeed the IMU time stamps are good (time since startup) but the driver callbacks do not occur at regular intervals leading to ROS header stamps being all over the place. This is not a problem if you go off the imu time stamps but a lot of ROS code goes by the header stamp since the sensor_msgs/Imu does not have a separate time stamp. I was planning on using your conversion node to run off of sensor_msgs/Imu messages, but that won't work unless the time stamps are good.

I will defile your beautiful driver by hacking in a time stamp adjustment. Feel free to ignore the PR :)

Answer 3 · 2021-12-30T14:38:58.000Z

Fixed with PR #88 and #91

Answer 4 · 2022-01-13T02:10:16.000Z

The root cause for the bad time stamps (and the symptoms themselves) are explained in PR #82.