Error message 0x29

[srirambadri]

Hi,

I used the driver a few weeks ago and it worked fine. I have a MTi 1-series Imu. But now I keep getting this error.

[INFO] [1493810349.866299]: Found parameter: ~device, value: auto
[INFO] [1493810349.871459]: Found parameter: ~baudrate, value: 0
[INFO] [1493810349.874029]: Found parameter: ~timeout, value: 0.002
[INFO] [1493810350.213101]: Detected MT device on port /dev/ttyUSB0 @ 115200 bps
[INFO] [1493810350.214387]: MT node interface: /dev/ttyUSB0 at 115200 bd.
Traceback (most recent call last):
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 726, in <module>
    main()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 721, in main
    driver = XSensDriver()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 59, in __init__
    self.mt = mtdevice.MTDevice(device, baudrate, timeout)
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 42, in __init__
    self.auto_config_legacy()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 621, in auto_config_legacy
    self.GetConfiguration()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 346, in GetConfiguration
    self._ensure_config_state()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 179, in _ensure_config_state
    self.GoToConfig()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 207, in GoToConfig
    self.write_ack(MID.GoToConfig)
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 164, in write_ack
    mid_ack, data_ack = self.read_msg()
  File "/home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 155, in read_msg
    raise MTErrorMessage(data[0])
mtdef.MTErrorMessage: Error message 0x29: Unknown error: 0x29
[xsens_driver-2] process has died [pid 24010, exit code 1, cmd /home/pem/student/sriram/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode.py __name:=xsens_driver __log:=/home/pem/.ros/log/538b8108-2ff2-11e7-912e-e4a7a0a4073b/xsens_driver-2.log].
log file: /home/pem/.ros/log/538b8108-2ff2-11e7-912e-e4a7a0a4073b/xsens_driver-2*.log

When I run the node alone ./mtdevice.py -c "wd2000fe,ad2000fe,mf100fe,ip2000,if2000,sw2000"

I get the following output for ./mtdevice.py -e {'Acceleration': {'frame': 'ENU', 'Delta v.z': 0.0808446928858757, 'Delta v.y': 0.05632352828979492, 'Delta v.x': -0.0009936298010870814}, 'Timestamp': {'PacketCounter': 1357, 'SampleTimeFine': 18223206}, 'Magnetic': {'magZ': -0.6049795150756836, 'frame': 'ENU', 'magX': 0.0735018253326416, 'magY': -0.30209970474243164}, 'Angular Velocity': {'Delta q1': -0.0037920873146504164, 'Delta q0': 0.9999767541885376, 'frame': 'ENU', 'Delta q2': -0.003788474015891552, 'Delta q3': 0.004226142540574074}, 'Status': {'StatusWord': 3}}

So what is causing this issue with the launch file?

[fcolas]

Hi, I found a more comprehensive list of error codes and yours corresponds to "XRV_DATAOVERFLOW" with the following message: "The device generates more data than the bus communication can handle (baud rate may be too low)." You might want to check whether you changed something in the configuration that would have caused this issue. On my side, I'll try to integrate all these messages in the driver in order to have a clearer message.

[fcolas]

I pushed a commit on the master branch with all the error messages I could find. If you try again, you should get a more helpful error message.

[srirambadri]

Hi,

Thanks for edit. I tried the new code but still get the same error. I traced down the error to a line in the code: (line 624) def read_measurement(self, mode=None, settings=None) In that,

else:
raise MTException("unknown data message: mid=0x%02X (%s)." % (mid, getMIDName(mid))

So I just returned Null when I don't have a message type that's not defined. This solved the issue but I couldn't find what was causing this unknown message type to be outputted by the sensor.

[fcolas]

Hi, This new exception means the IMU is sending a message type that is unknown to the driver. It is different than the original one that was a message of known type (error) but with an unknown content (error number). You can mute the error but if it's reproducible, it might be more interesting to investigate and try to solve it properly. Can you paste me the full error message, please?

[fcolas]

Any news on that? If you give up, I cannot improve the driver.

[srirambadri]

Hi, I'm really sorry I wasn't notified on your previous comment and therefore couldn't reply. So here's the full error message

`process[xsens_driver-2]: started with pid [26432]
[INFO] [1500299647.267439]: Found parameter: ~device, value: auto
[INFO] [1500299647.272426]: Found parameter: ~baudrate, value: 0
[INFO] [1500299647.277256]: Found parameter: ~timeout, value: 0.002
[INFO] [1500299647.636629]: Detected MT device on port /dev/ttyUSB0 @ 115200 bps
[INFO] [1500299647.638051]: MT node interface: /dev/ttyUSB0 at 115200 bd.

Traceback (most recent call last):
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 726, in <module>
    main()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 721, in main
    driver = XSensDriver()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 59, in __init__
    self.mt = mtdevice.MTDevice(device, baudrate, timeout)
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 43, in __init__
    self.auto_config_legacy()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 622, in auto_config_legacy
    self.GetConfiguration()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 347, in GetConfiguration
    self._ensure_config_state()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 180, in _ensure_config_state
    self.GoToConfig()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 208, in GoToConfig
    self.write_ack(MID.GoToConfig)
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 165, in write_ack
    mid_ack, data_ack = self.read_msg()
  File "/home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 156, in read_msg
    raise MTErrorMessage(data[0])
mtdef.MTErrorMessage: Error message 0x29: The device generates more data than the bus communication can handle (baud rate may be too low)
[xsens_driver-2] process has died [pid 26432, exit code 1, cmd /home/pem/student/sriram/new_ws/src/ethzasl_xsens_driver/nodes/mtnode.py __name:=xsens_driver __log:=/home/pem/.ros/log/66352f58-6af7-11e7-a73a-e4a7a0a4073b/xsens_driver-2.log].
log file: /home/pem/.ros/log/66352f58-6af7-11e7-a73a-e4a7a0a4073b/xsens_driver-2*.log`

[srirambadri]

I know it says Baud rate may be too low but when I set it manually to 115200 it still gives the same error

[fcolas]

No problem. 115200 is the default baudrate and some devices don't really support all the possible baudrates. Maybe the problem is more that you're asking for too much data. How is your device configured? Can you paste the output of: rosrun xsens_driver mtdevice.py -i

[srirambadri]

Device: /dev/ttyUSB0 at 115200 Bd:
  device ID:  0x038804AD
  product code: 'MTI-3-8A7G6'
  firmware revision: (1, 1, 1)
  baudrate: 2
  error mode:  MTException: Timeout: waiting for message

[fcolas]

It seems to be a problem with MTi 1-series to not properly answer messages they don't know. Can you check my comment in #51 on the inspection and see if you can do that to solve the inspection issue? Once that's done, we can take a proper look at the configuration and see to solve your issue.

[srirambadri]

Hi,

So I commented out these lines and this is the output I get without any timeout error.

try_message("error mode:", mt.GetErrorMode, hex_fmt(2))
try_message("transmit delay:", mt.GetTransmitDelay) 
try_message("string output type:", mt.GetStringOutputType)
try_message("alignment rotation sensor:", mt.GetAlignmentRotation,parameter=0)
try_message("alignment rotation local:", mt.GetAlignmentRotation,parameter=1)
try_message("extended output mode:", mt.GetExtOutputMode, hex_fmt(2))
try_message("UTC time:", mt.GetUTCTime)

Device: /dev/ttyUSB0 at 115200 Bd:
  device ID:  0x038804AD
  product code: 'MTI-3-8A7G6'
  firmware revision: (1, 1, 1)
  baudrate: 2
  option flags:  0x00000090
  location ID:  0x0000
  synchronization settings:  []
  general configuration: {   'Master device ID': 59245741,
    'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
    'device ID': 59245741,
    'length': 888,
    'number of devices': 1,
    'output-mode': 0,
    'output-settings': 1,
    'period': 1152,
    'skipfactor': 0,
    'time': '\x00\x00\x00\x00\x00\x00\x00\x00'}
  output configuration (mark IV devices):  [(0x1020, 65535), (0x1060, 65535), (0x2010, 100), (0x4020, 100), (0x4010, 100), (0x8020, 100), (0x8030, 100), (0xE020, 65535)]
  period: 1152
  output mode:  0x0000
  output settings:  0x00000001
  GPS coordinates (lat, lon, alt): (52.24049169408207, 6.838216771186439, 0.0)
  available scenarios: [   (50, 7, 'general'),
    (51, 7, 'high_mag_dep'),
    (52, 7, 'dynamic'),
    (53, 7, 'north_reference'),
    (54, 7, 'vru_general')]
  current scenario ID: 50

[fcolas]

Great, many thanks for your work. I'll push a quick fix soon.

[fcolas]

I pushed a fix_mt1_series_inspect branch. Could you please try it out? Thanks again.

[fcolas]

@srirambadri if you could test the branch before I merge #60 it would be great.

As for your original issue. Did you try remove some of the info, or just to lower the frequency?

[guilhermeguimaraes]

I am also having problems with the driver. I git cloned the fix_mt1_series_inspection and the launch file generates the following output: [ERROR] [1511886468.072091]: Fatal: could not find proper MT device.

[guilhermeguimaraes]

I am using a MT1-1s IMU with Ubuntu 16.04 and ROS Kinetic

[fcolas]

@guilhermeguimaraes This doesn't seem to be the same issue. The issue here is about Error message 0x29. Maybe you want to take a look at #55.

[tbarchyn]

Possibly of help: I can reproduce this 0x29 bug. I have a new MTi-3, the configuration output from mtdevice.py -i is:

Device: /dev/ttyUSB0 at 115200 Bd:
  device ID:  0x03881F5C
  product code: 'MTi-3-8A7G6'
  firmware revision: (1, 2, 1)
  baudrate: 2
  error mode:  timeout: might be unsupported by your device.
  option flags:  0x00000000
  location ID:  0x0000
  transmit delay:  timeout: might be unsupported by your device.
  synchronization settings:  []
  general configuration: {   'Master device ID': 59252572,
    'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
    'device ID': 59252572,
    'length': 888,
    'number of devices': 1,
    'output-mode': 0,
    'output-settings': 0,
    'period': 1152,
    'skipfactor': 0,
    'time': '\x00\x00\x00\x00\x00\x00\x00\x00'}
  output configuration (mark IV devices):  [(0x1020, 65535), (0x1060, 65535), (0x2030, 20), (0xE020, 65535)]
  string output type:  timeout: might be unsupported by your device.
  period: 1152
  alignment rotation sensor: (0, (1.0, 0.0, 0.0, 0.0))
  alignment rotation local: (1, (0.0, -0.7071067690849304, -0.7071067690849304, -0.0))
  output mode:  0x0000
  extended output mode:  timeout: might be unsupported by your device.
  output settings:  0x00000000
  GPS coordinates (lat, lon, alt): (49.1777, -123.92964, 0.0)
  available scenarios: [   (50, 8, 'general'),
    (51, 8, 'high_mag_dep'),
    (52, 8, 'dynamic'),
    (53, 8, 'north_reference'),
    (54, 8, 'vru_general')]
  current scenario ID: 50
  UTC time: (0, 1970, 1, 1, 0, 0, 0, 0)

When running mtdevice.py -v to print out the verbose mode output, this is the output before the crash:

MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
waiting for 35 bytes, got 32 so far: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00]
MT: Got message id 0x36 (MTData2) with 34 data bytes: [10 20 02 00 16 10 60 04 00 A5 60 8C 20 30 0C C3 2A 6F F3 3D 9A CB E1 C3 17 41 33 E0 20 04 00 00 00 03]
ack (0x31) expected, got 0x36 instead
MT: Got message id 0x36 (MTData2) with 34 data bytes: [10 20 02 00 17 10 60 04 00 A5 62 80 20 30 0C C3 2A 71 59 3D 93 2B 58 C3 17 40 19 E0 20 04 00 00 00 03]
ack (0x31) expected, got 0x36 instead
MT: Got message id 0x36 (MTData2) with 34 data bytes: [10 20 02 00 18 10 60 04 00 A5 64 74 20 30 0C C3 2A 72 25 3D 8B CF 12 C3 17 3F 35 E0 20 04 00 00 00 03]
ack (0x31) expected, got 0x36 instead
MT: Got message id 0x42 (Error) with 1 data bytes: [29]
MTErrorMessage: Error message 0x29: The device generates more data than the bus communication can handle (baud rate may be too low)

A few other points of info that possibly may be of help:

1. this happens every second time I run mtdevice.py: works, fails, works, fails, etc. Maybe it is failing to switch from config to measurement mode or something similar?
2. increasing the timeout arg to MTDevice to >0.05 s seems to make it work, but this may not be the best choice?

Thanks in advance for any ideas.

Tom

[fcolas]

Many thanks for your information. It's quite puzzling. I guess the same happens when you run the ROS node instead of mtdevice.py, right? But does it also happen for mtdevice.py -i every second time?

In your log, it does happen while switching the device to config mode. Indeed, the first thing the driver does is this switch, in order to know what to expect as data (it was useful for mark III devices but since the inception of MTData2, it is useless). Most command messages, like changing to config mode, expect a acknowledgement message which should get send right away but in measurement mode there are often queued data messages that remain before reading the expected ack. What is especially weird in your case is that you ask for a low volume of data (around 40 bytes at 20 Hz) and, while the device is supposed to not send them any more, it complains that it generates too much data.

The fact that it happens every second time is also intriguing. What could happen is that, when it fails with this error, it still switches to config mode and the next time we try to switch it is already in this mode, but then with the echo command (default for mtdevice.py) it switches back to measurement mode before outputting the message contents. That is why I wonder if it happens with successive calls to mtdevice.py -i.

There are three things we could do:

• getting rid of this automatic going into config mode when it is not needed (doesn't solve the issue per se but makes it less frequent and especially in the node);
• catching this specific error after going to config mode (not more satisfactory);
• asking for support from Xsens.

What are your thoughts?

[tbarchyn]

Thanks for the ideas. I don't have ROS working now on this computer, so my apologies, I cannot test the node part of this.

But to answer your second question: when calling mtdevice.py -i repeatedly, it doesn't crash. So yes, likely this is issue with the device being in measurement mode, then being forced into config mode.

One possibility is that the self.device.flushInput () call in __init__ method isn't succeeding in flushing the input buffer. I seem to remember from a previous project that pyserial returns right away when first opening the connection, but the connection might not be open yet with the OS, so the self.device.flushInput () call maybe is timing out waiting for the os to get itself organized, and the buffer doesn't get flushed. The time it takes for the serial connection to actually open with the OS I suppose would vary among platforms and computers. I don't have a great understanding of exactly how pyserial works though under the hood.

I added a 0.1 s time.sleep call right after opening the serial connection but before flushing the buffers: https://github.com/tbarchyn/ethzasl_xsens_driver/blob/0x29_fixes/nodes/mtdevice.py#L36

This seems to solve the problem here, but I'm not fully sure if it is a general fix.

[fcolas]

@tbarchyn I've added the initial_wait parameter as suggested. @srirambadri Can you check that it solves your issue?

[snakehaihai]

I also had this long line of bullshit error earlier today.

Then I read some post in xsense says that might be compass fucked up ask me to recalibrate.

What I do is I go to windows and download xsense suit.

There I change the sensor config to allow 921600 output rate.
Output config unchecks most of the output(specially for compass) only left orientation delta q delta t acceleration stuff at 400 hz. Remove all 2000hz stuff. And it works. Might work for you as well

For the output config, you might want to spend some time to find the correct checklist as I`m using MTI 300. So there could have some difference with a different model. The concept should be the same

Hope it helps with your case

[pedrobagatin]

Solved it by going MT Manager on Windows and setting its baud rate to 230400. After, using Linux edited mtdevice.py baudrate from 115200 to 230400.

default values device = '/dev/ttyUSB0' baudrate = 230400

And run the file python2 mtdevice.py. That is it!

[fcolas]

Ok so this can be solved by changing the baud rate. Closing.