Issue in --deprecated-skip-factor

[ghost]

It seems that the minimum freq these IMUs can deliver is 100Hz. For many applications this unnecessarily overloads the system. In our case we are using a 32 bit processor and the 100Hz IMU message calculation, publishing and rosbagging consumes over 90% of a core.
It would be a nice feature if the node would allow specifying a frequency (say 20 Hz) or a filtering factor (say every 5th message) and average messages (low pass filter) before publishing at a lower rate.

[fcolas]

Well, I don't believe it fits in the driver. First, you should be able to configure your device to output way lower rates than 100Hz. Did you try to do it (see the documentation of your IMU and/or of mtdevice.py)? Second, there is already a generic ROS tool for throttling messages [1]. And third, the ROS (and UNIX) philosophy is more to have simpler nodes that perform a service well rather than a single big tool that tries to do everything. As such, if you want to apply a low-pass filter on your IMU measurement before recording it in a ROS bag, you should do it in a separate node.

In your case, with limited resource, the simplest seems to be to better configure your IMU.

[1] http://wiki.ros.org/topic_tools/throttle

[ghost]

@fcolas thanks for the info. Looks like I missed the skip-factor setting for the IMU. We have an old MTi with limited documentation. I think I have a couple ideas to try now. Cheers.

[ghost]

@fcolas a quick question. I am trying to change our IMU frequency using the skip-factor option, but am not able to do it. The command I am using is:rosrun xsens_driver mtdevice.py -d /dev/ttyCTI1 -l --output-settings=tqMAG --output-mode=tcos --deprecated-skip-factor=4 However, this is not changing the frequency. Could you possibly point me in the right direction.

Doing a -i on our device shows

Device: /dev/ttyCTI1 at 115200 Bd:
  device ID:  0x01301262
  product code: 'MTi-28A53G35'
  firmware revision: (2, 6, 1)
  baudrate: 2
  error mode:  0x0001
  option flags:  message unsupported by your device.
  location ID:  0x0000
  transmit delay:  message unsupported by your device.
  synchronization settings:  message unsupported by your device.
  general configuration: {   'Master device ID': 19927650,
    'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
    'device ID': 19927650,
    'length': 59,
    'number of devices': 1,
    'output-mode': 2055,
    'output-settings': 1,
    'period': 1152,
    'skipfactor': 0,
    'time': '\x00\x00\x00\x00\x00\x00\x00\x00'}
  output configuration (mark IV devices):  message unsupported by your device.
  string output type: 0
  period: 1152
  alignment rotation sensor:  message unsupported by your device.
  alignment rotation local:  message unsupported by your device.
  output mode:  0x0807
  extended output mode:  0x0000
  output settings:  0x00000001
  GPS coordinates (lat, lon, alt): (52.2404899597168, 6.838216781616211, 0.0)
  available scenarios: [   (4, 9, 'human'),
    (5, 9, 'human_large_accel'),
    (6, 9, 'machine'),
    (7, 9, 'machine_nomagfield'),
    (8, 9, 'marine')]
  current scenario ID: 5
  UTC time:  message unsupported by your device.

Thanks,

[fcolas]

Well, the command line seems correct. Could you try it again with the verbose -v flag and paste the full output here?

[ghost]

@fcolas I don't have the sensor with me, so won't be able to do that. However I was able to fix the issue by using the -f option instead. So the full command was rosrun xsens_driver mtdevice.py -d /dev/ttyCTI1 -l --output-settings=tqMAG --output-mode=tcos -f 4

[fcolas]

Oops, it's a stupid command-line parsing bug. Many thanks for the catch!

[fcolas]

Solved in b26e785