ethz-asl / ethzasl_xsens_driver Goto Github PK
View Code? Open in Web Editor NEWDriver for xsens IMUs
License: BSD 2-Clause "Simplified" License
Driver for xsens IMUs
License: BSD 2-Clause "Simplified" License
Note: this driver is not maintained anymore. For ROS 2 support, see https://github.com/norlab-ulaval/norlab_xsens_driver ROS Driver for XSens MT/MTi/MTi-G devices. See: http://ros.org/wiki/ethzasl_xsens_driver
I had the MT error: timeout waiting for message
issue with the mtdevice.py node as in this issue. Following the discussion, I checked that the configuration occurs anyways by changing the period with -p
and seeing the effect with the -i
command. So, ignoring the error message in the configuration step and running mtnode_new
I am able to see the imu/data
but nothing is returned with /fix
,/fix_extended
and /temperature
when using rostopic echo
. However, I am only interested in the GPS data.
Here is the configuration command I run :
rosrun xsens_driver mtdevice.py --configure --output-mode=tcoapvsgr --output-settings=tqMAG
Corresponding output :
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 01 B1 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 01 B1 00 00 58 3F 00 00 00 01 04 01 01 03 01 37 02 02]
MT: Write message id 0x10 (GoToMeasurement) with 0 data bytes: []
MT: Got message id 0x11 (GoToMeasurementAck) with 0 data bytes: []
Configuring mode and settings MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0xD0 (SetOutputMode) with 2 data bytes: [58 3F]
MT: Got message id 0xD1 (SetOutputModeAck) with 0 data bytes: []
MT: Write message id 0xD2 (SetOutputSettings) with 4 data bytes: [00 00 00 01]
MT: Got message id 0xD3 (SetOutputSettingsAck) with 0 data bytes: []
MT: Write message id 0xD0 (SetOutputMode) with 0 data bytes: []
MT: Got message id 0xD1 (SetOutputModeAck) with 2 data bytes: [58 3F]
MT: Write message id 0xD2 (SetOutputSettings) with 0 data bytes: []
MT: Got message id 0xD3 (SetOutputSettingsAck) with 4 data bytes: [00 00 00 01]
MT: Write message id 0x0A (ReqDataLength) with 0 data bytes: []
MT error 0x04: Invalid message.MT: Got message id 0x42 (Error) with 5 data bytes: [04 00 00 00 00]
MT error: timeout waiting for message.
Also here is the inspection command I run :
rosrun xsens_driver mtdevice.py -i
And the corresponding output:
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 01 B1 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 01 B1 00 00 58 3F 00 00 00 01 04 01 01 03 01 37 02 02]
MT: Write message id 0x10 (GoToMeasurement) with 0 data bytes: []
MT: Got message id 0x11 (GoToMeasurementAck) with 0 data bytes: []
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
Device: /dev/ttyUSB0 at 115200 Bd:
General configuration: MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 01 B1 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 01 B1 00 00 58 3F 00 00 00 01 04 01 01 03 01 37 02 02]
{'output-settings': 1, 'device ID': 124780977, 'length': 0, 'skipfactor': 0, 'number of devices': 1, 'time': '\x00\x00\x00\x00\x00\x00\x00\x00', 'date': '\x00\x00\x00\x00\x00\x00\x00\x00', 'output-mode': 22591, 'Master device ID': 124780977, 'period': 576}
Available scenarios: MT: Write message id 0x62 (ReqAvailableScenarios) with 0 data bytes: []
MT: Got message id 0x63 (AvailableScenarios) with 110 data bytes: [01 04 47 65 6E 65 72 61 6C 20 20 20 20 20 20 20 20 20 20 20 20 20 02 04 47 65 6E 65 72 61 6C 4E 6F 42 61 72 6F 20 20 20 20 20 20 20 03 04 47 65 6E 65 72 61 6C 4D 61 67 20 20 20 20 20 20 20 20 20 20 04 04 41 75 74 6F 6D 6F 74 69 76 65 20 20 20 20 20 20 20 20 20 20 05 04 41 75 74 6F 55 72 62 61 6E 43 61 6E 79 6F 6E 20 20 20 20 20]
[(1, 4, 'General'), (2, 4, 'GeneralNoBaro'), (3, 4, 'GeneralMag'), (4, 4, 'Automotive'), (5, 4, 'AutoUrbanCanyon')]
MT: Write message id 0x64 (SetCurrentScenario) with 0 data bytes: []
MT: Got message id 0x65 (SetCurrentScenarioAck) with 2 data bytes: [04 01]
Current scenario: (id: 1025)
MT: Write message id 0x10 (GoToMeasurement) with 0 data bytes: []
MT: Got message id 0x11 (GoToMeasurementAck) with 0 data bytes: []
Thanks a lot for the effort you invest in aiding others, and hope you can help me getting the GPS data to be read.
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.
Traceback (most recent call last):
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 717, in
main()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 713, in main
driver.spin()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 122, in spin
self.spin_once()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 684, in spin_once
if self.pub_analog_in1_pub is None:
AttributeError: 'XSensDriver' object has no attribute 'pub_analog_in1_pub'
pub_analog_in1_pub, typo with pub both in front and back?
Update:
Made a pull request with the typo fixed, "analog_in1_pub" seem to be the intended name considering the next line in the code and it seem to work.
I got the following error when running the driver from roslaunch
[INFO] [1528494566.684170]: Found parameter: ~device, value: /dev/ttyUSB0
[INFO] [1528494566.687142]: Found parameter: ~baudrate, value: 0
[INFO] [1528494566.690184]: Found parameter: ~timeout, value: 0.002
[INFO] [1528494566.713816]: MT node interface: /dev/ttyUSB0 at 115200 bd.
[INFO] [1528494566.794297]: Found parameter: ~no_rotation_duration, value: 0
[INFO] [1528494566.797536]: Found parameter: ~frame_id, value: /imu
[INFO] [1528494566.801692]: Found parameter: ~frame_local, value: ENU
Traceback (most recent call last):
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 726, in <module>
main()
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 722, in main
driver.spin()
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 131, in spin
self.spin_once()
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtnode.py", line 638, in spin_once
data = self.mt.read_measurement()
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 632, in read_measurement
return self.parse_MTData2(data)
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 912, in parse_MTData2
raise MTException("fixed point precision not supported.")
mtdef.MTException: fixed point precision not supported.
This is what I got from mtdevice.py -i
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: 0x077010E6
product code: 'MTi-G-710-2A5G4'
firmware revision: (1, 4, 12)
baudrate: 2
error mode: message unsupported by your device.
option flags: 0x00000000
location ID: 0x0000
transmit delay: message unsupported by your device.
synchronization settings: [(0x09, 0x01, 0x01, 0x00, 0x0000, 0x0000, 0x0000, 0x00FA)]
general configuration: { 'Master device ID': 124784870,
'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
'device ID': 124784870,
'length': 0,
'number of devices': 1,
'output-mode': 6,
'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), (0x1010, 65535), (0x2030, 100), (0x4020, 100), (0x4010, 100), (0x8020, 100), (0x8030, 100), (0xE020, 65535), (0x5042, 100), (0x5022, 100), (0xD012, 100), (0x7010, 4), (0x8840, 4), (0x1030, 65535)]
string output type: 0
period: 1152
alignment rotation sensor:
Traceback (most recent call last):
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1903, in <module>
main()
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1548, in main
inspect(mt, device, baudrate)
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1667, in inspect
parameter=0)
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1643, in try_message
pprint.pprint(f(*args, **kwargs), indent=4)
File "/home/zeng/ros_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 428, in GetAlignmentRotation
param, q0, q1, q2, q3 = struct.unpack('!Bffff', data)
struct.error: unpack requires a string argument of length 17
This is what I got from mtdevice.py
{'Acceleration': {'Delta v.z': 0.09774729609489441, 'Delta v.y': 0.0019016989972442389, 'Delta v.x': -0.005384126212447882, 'frame': 'ENU', 'accY': 0.19037173688411713, 'accX': -0.5384865403175354, 'accZ': 9.774721145629883}, 'Timestamp': {'Hour': 21, 'PacketCounter': 42124, 'Month': 6, 'Second': 17, 'Flags': 247, 'Year': 2018, 'ns': 734600000, 'Day': 8, 'Minute': 52, 'SampleTimeFine': 26266257}, 'Orientation Data': {'Yaw': 0.03150816261768341, 'Pitch': 3.0332014560699463, 'frame': 'ENU', 'Roll': 1.0015487670898438}, 'Angular Velocity': {'Delta q1': 1.0609558557916898e-05, 'Delta q0': 1.0, 'Delta q3': -5.172616511117667e-06, 'Delta q2': 3.682477199618006e-06, 'frame': 'ENU', 'gyrZ': -0.0010345234768465161, 'gyrX': 0.002121912082657218, 'gyrY': 0.0007364954799413681}, 'Status': {'StatusWord': 25166021}}
TimeReference message member is named time_ref.
http://docs.ros.org/api/sensor_msgs/html/msg/TimeReference.html
There are two lines that refer to time_ref_msg.time
Works after changing to time_ref_msg.time_ref
I just got a MTI-300 which i would like to run with ROS. Im running Ubuntu 12.04 with kernel 3.5.027. I used this kernel https://github.com/xsens/xsens_mt module to have the MTI USB device shown up as ttyUSB0 device. The xsens examples are running fine.
But:
roslaunch xsens_driver xsens_driver.launch
returns following:
[WARN] [WallTime: 1367338099.920318] Cannot find value for parameter: ~device, assigning default: auto
[WARN] [WallTime: 1367338099.921856] Cannot find value for parameter: ~baudrate, assigning default: 0
MT error 0x04: Invalid message.[ERROR] [WallTime: 1367338100.042764] Fatal: could not find proper MT device.
In this post are the same issues mentioned
http://answers.ros.org/question/56635/xsens-error-comunicating-with-ubuntu-1204/#56959
any ideas how to fix it?
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?
Hello!
How to run command SetNoRotation at startup so to calibrate the MTi-3?
It is in mtdevice.py
Thank you
First of all, I want to thank you for this repository. I tried the code from xsens for MTw devices and nothing works! But this code seems to work somehow, although there is something different for MTw2 devices.
Running inspect I got:
./mtdevice.py -i
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: 0x00B4126B
product code: 'MTW2-3A7G6'
firmware revision: (4, 0, 2)
baudrate: 2
error mode: MTException: Timeout: waiting for message
If I run the node, on the /imu/data there is not orientation data, while the other fields contain nans or close to zero values. This is an output of ./mtdevice -e:
{'Calib': {'magZ': nan, 'magY': 6.310593491255738e-40, 'magX': nan, 'frame': 'ENU', 'accY': nan, 'accX': nan, 'accZ': 1.4695075078549061e-38, 'gyrZ': nan, 'gyrX': nan, 'gyrY': 1.4158719683537952e-41}}'
Can you help me with this type of device?
I am using MTi-G-710. It outputs Velocity messages but all the linear velocity message have 0 values. Can someone help me with this?
http://wiki.ros.org/xsens_driver#mtdevice.py contains the documentation of mtdevice.py
. However, it is outdated and does not match the upstream usage anymore.
Can you please update the ROS wiki page?
Cheers
Since we upgraded the firmware on our devices to version 1.8.2 we observe errors with the mtdevice.py -i
script. Apparantly the response received is longer than expected, and thus it fails to parse given the pattern.
Here is the output for example:
$ rosrun xsens_driver mtdevice.py -i
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: 0x077003D4
product code: 'MTi-G-700-2A5G4'
firmware revision: (1, 8, 2)
baudrate: 2
error mode: message unsupported by your device.
option flags: 0x00000010
location ID: 0x0000
transmit delay: message unsupported by your device.
synchronization settings: [(0x09, 0x01, 0x01, 0x00, 0x0000, 0x0000, 0x0000, 0x00FA)]
general configuration: { 'Master device ID': 124781524,
'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
'device ID': 124781524,
'length': 0,
'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), (0x2013, 400), (0x4023, 400), (0x8023, 400), (0x5043, 400), (0xD013, 400)]
string output type: 0
period: 1152
alignment rotation sensor:
Traceback (most recent call last):
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 1704, in <module>
main()
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 1430, in main
inspect(mt, device, baudrate)
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 1530, in inspect
parameter=0)
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 1508, in try_message
pprint.pprint(f(*args, **kwargs), indent=4)
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 424, in GetAlignmentRotation
q0, q1, q2, q3 = struct.unpack('!ffff', data)
struct.error: unpack requires a string argument of length 16
The actual data received is this: bytearray(b'\x00?\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
(length: 17).
When I slice off a byte at the front or at the back of the buffer, the script continues without any other obvious errors raised. The device produces data seemingly normal (as long as you don't configure it to produce fixed-point GPS coordinates, I recall). We observed occasional crashes recently, for which we didn't find the cause so far.
Now I wonder, did we break the device (with the firmware update?) or is the driver incompatible? Can anyone confirm the problem or help resolve the issue?
It's been a year since the last version... What about releasing a new one? :)
Due to the while loop at https://github.com/ethz-asl/ethzasl_xsens_driver/blob/master/xsens_driver/nodes/mtdevice.py#L58 , the software waits for incoming serial data to stop before writing any output. This causes a hang with the xsens MTi that I'm using.
Commenting out this while loop seems to resolve the problem for me, but perhaps this breaks something else?
Hi, I understand that this driver uses the East-North-Up definition as per REP-103. I wanted to be sure I understand what this means. See below for a simple URDF I had created which shows the imu_base_link in the standard forward-left-up frame & the imu link which is in the East-North-Up frame.
Am I interpreting this correctly?
Thanks in advance.
Hey,
First of all thanks for the drivers. I am using an MTi-10 and when I run the mtnode.py
node i don't seem to get the angular velocity data. But when i run rosrun xsens_driver mtdevice.py -m 2 -f 10
I seem to get angular velocity values. The output of the console is
started roslaunch server http://tegra-ubuntu:33887/
SUMMARY
========
PARAMETERS
* /rosdistro: kinetic
* /rosversion: 1.12.7
* /xsens_driver/baudrate: 115200
* /xsens_driver/device: /dev/xsens
* /xsens_driver/frame_id: xsens
* /xsens_driver/frame_local: ENU
* /xsens_driver/no_rotation_duration: 0
* /xsens_driver/timeout: 0.002
NODES
/
xsens_driver (xsens_driver/mtnode.py)
ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[xsens_driver-1]: started with pid [11925]
[INFO] [1498763213.397881]: Found parameter: ~device, value: /dev/xsens
[INFO] [1498763213.401874]: Found parameter: ~baudrate, value: 115200
[INFO] [1498763213.406158]: Found parameter: ~timeout, value: 0.002
[INFO] [1498763213.407166]: MT node interface: /dev/xsens at 115200 bd.
[INFO] [1498763213.456293]: Found parameter: ~no_rotation_duration, value: 0
[INFO] [1498763213.459914]: Found parameter: ~frame_id, value: xsens
[INFO] [1498763213.463558]: Found parameter: ~frame_local, value: ENU
[WARN] [1498763229.732860]: Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.
^C[xsens_driver-1] killing on exit
Traceback (most recent call last):
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 726, in <module>
main()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 722, in main
driver.spin()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 131, in spin
self.spin_once()
File "/opt/ros/kinetic/lib/xsens_driver/mtnode.py", line 638, in spin_once
data = self.mt.read_measurement()
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 628, in read_measurement
mid, data = self.read_msg()
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 131, in read_msg
if ord(self.waitfor()) != 0xFA:
File "/opt/ros/kinetic/lib/xsens_driver/mtdevice.py", line 81, in waitfor
buf.extend(self.device.read(size-len(buf)))
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 511, in read
raise SerialException('read failed: %s' % (e,))
serial.serialutil.SerialException: read failed: (4, 'Interrupted system call')
shutting down processing monitor...
... shutting down processing monitor complete
done
and the rostopic echo message is
---
header:
seq: 894
stamp:
secs: 1498763229
nsecs: 714687108
frame_id: xsens
orientation:
x: 0.0
y: 0.0
z: 0.0
w: 0.0
orientation_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
angular_velocity:
x: 0.0
y: 0.0
z: 0.0
angular_velocity_covariance: [-1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0, -1.0]
linear_acceleration:
x: -0.000661169760861
y: 0.00464787147939
z: 0.0979677215219
linear_acceleration_covariance: [0.0004, 0.0, 0.0, 0.0, 0.0004, 0.0, 0.0, 0.0, 0.0004]
---
Any help is appreciated.
Thanks
I'm not quite sure if this is related to #32
Setup:
xsens_driver
from apt: 2.0.1When calling:
rosrun xsens_driver mtdevice.py -iv
the script crashes with the following output:
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [03 60 08 A6 04 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 03 60 08 A6 00 00 00 00 00 00 00 00 00 27 01 04 0C 49 04 00]
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: MT: Write message id 0x00 (ReqDID) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x01 (DeviceID) with 4 data bytes: [03 60 08 A6]
0x036008A6
product code: MT: Write message id 0x1C (ReqProductCode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x1D (ProductCode) with 20 data bytes: [4D 54 69 2D 33 30 2D 32 41 35 47 34 20 20 20 20 20 20 20 20]
'MTi-30-2A5G4'
firmware revision: MT: Write message id 0x12 (ReqFWRev) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x13 (FirmwareRev) with 11 data bytes: [01 04 0C 00 00 00 0D 00 00 D5 76]
(1, 4, 12)
baudrate: MT: Write message id 0x18 (SetBaudrate) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x19 (SetBaudrateAck) with 1 data bytes: [02]
2
error mode: MT: Write message id 0xDA (SetErrorMode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x42 (Error) with 5 data bytes: [04 00 00 00 00]
message unsupported by your device.
option flags: MT: Write message id 0x48 (SetOptionFlags) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x49 (SetOptionFlagsAck) with 4 data bytes: [00 00 00 00]
Traceback (most recent call last):
File "/home/mig/git/sandbox_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1704, in <module>
main()
File "/home/mig/git/sandbox_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1430, in main
inspect(mt, device, baudrate)
File "/home/mig/git/sandbox_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1520, in inspect
try_message("option flags:", mt.GetOptionFlags, hex_fmt(8))
File "/home/mig/git/sandbox_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 1506, in try_message
print formater(f(*args, **kwargs))
File "/home/mig/git/sandbox_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 288, in GetOptionFlags
set_flags, clear_flags = struct.unpack('!II', data)
struct.error: unpack requires a string argument of length 8
Commenting out line 1520 does the trick and it works perfectly.
rosrun xsens_driver mtdevice.py -e
rosrun xsens_driver mtnode.py
without any parameters set work fine (even though the node somtimes complains about Inbound TCP/IP connection failed: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.
when echoing the topics)
Hi,
I am trying to use MTi-G with GPS on ROS.
Most of the time I get this output
rosrun xsens_driver mtdevice.py -i
MTException: Timeout: waiting for message
Sometimes I get this output
rosrun xsens_driver mtdevice.py -i
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: 0x01500618
product code: 'MTi-G-28A53G35'
firmware revision: (2, 6, 1)
baudrate: 2
error mode: MTException: Timeout: waiting for message
If I run this command I get this output
roslaunch xsens_driver xsens_driver.launch
[WARN] [1521809140.589618]: Cannot find value for parameter: ~device, assigning default: auto
[WARN] [1521809140.592510]: Cannot find value for parameter: ~baudrate, assigning default: 0
[WARN] [1521809140.595244]: Cannot find value for parameter: ~timeout, assigning default: 0.002
[INFO] [1521809140.672131]: Detected MT device on port /dev/ttyUSB0 @ 115200 bps
[INFO] [1521809140.672670]: MT node interface: /dev/ttyUSB0 at 115200 bd.
[INFO] [1521809140.724260]: Found parameter: ~frame_id, value: /imu
[INFO] [1521809140.727137]: Found parameter: ~frame_local, value: ENU
By the way, I am able to see
rostopic list
/imu/correction_angle
/imu/correction_angle_pitch
/imu/correction_angle_roll
/imu/data
/imu/mag
/imu/view_data
/imu_data_str
/rosout
/rosout_agg
/velocity
But I have GPS connected also so I want to see longitude, latitude, and altitude. Any solution?
Thanks.
Hello, I've been using a slightly modified version of these drivers with a MTi 1-series Development Kit (with the MTi-3-8A7G6 sensor) for some time without any problem.
I recently updated the firmware from FW 1.0.6 version to the lates, FW 1.0.12 version and now, when I launch the xsens_driver.launch file I'm seeing the following error:
SUMMARY
PARAMETERS
- /rosdistro: indigo
- /rosversion: 1.11.19
- /xsens_driver/frame_id: imu
- /xsens_driver/frame_local: ENU
- /xsens_driver/frame_local_imu: ENU
NODES
/
xsens_driver (xsens_driver/mtnode_new.py)ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[xsens_driver-1]: started with pid [25162]
[WARN] [WallTime: 1462986141.530980] Cannot find value for parameter: ~device, assigning default: auto
[WARN] [WallTime: 1462986141.531970] Cannot find value for parameter: ~baudrate, assigning default: 0
[INFO] [WallTime: 1462986141.621873] Detected MT device on port /dev/ttyUSB0 @ 115200 bps
[INFO] [WallTime: 1462986141.622076] MT node interface: /dev/ttyUSB0 at 115200 bd.
[INFO] [WallTime: 1462986141.663337] Found parameter: ~frame_id, value: imu
Traceback (most recent call last):
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode_new.py", line 495, in
main()
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode_new.py", line 491, in main
driver.spin()
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode_new.py", line 111, in spin
self.spin_once()
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtnode_new.py", line 448, in spin_once
data = self.mt.read_measurement()
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 390, in read_measurement
mid, data = self.read_msg()
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 120, in read_msg
if ord(waitfor())<>0xFA:
File "/home/gautam/catkin_ws/src/ethzasl_xsens_driver/nodes/mtdevice.py", line 118, in waitfor
raise MTException("timeout waiting for message.")
mtdef.MTException: MT error: timeout waiting for message.
I'm running these drivers in ROS Indigo and everything was running perfectly with the previous firmware! It seems that after the firmware update the raw messages from the IMU is not being read by the ROS drivers(or maybe they are not in the correct format?).
I also tried testing the IMU in the MT software suite V4.5.4 provided by xsens MT_Software_Suite_Linux_4.5.4 with the latest firmware(FW 1.0.12). Even though I was able to visualize the data from the IMU, I was getting the following out on my terminal window:
./mtmanager
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(351) setLogLevel Log level switched to [ERROR]
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(365) setDebugLevel Debugger output log level switched to [FATAL]
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(207) writeFileHeader Journaller logging to /home/gautam/.local/share/Xsens/mtmanager/xda.log for xda
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(208) writeFileHeader Current log level is [ERROR]
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(212) writeFileHeader Journaller is not using threaded logging
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(365) setDebugLevel Debugger output log level switched to [FATAL]
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(207) writeFileHeader Journaller logging to /home/gautam/.local/share/Xsens/mtmanager/mtmanager.log for MT Manager
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(208) writeFileHeader Current log level is [ERROR]
1462986440.721 <740B4780> [WRITE] /home/builder/.pulse2-agent/data/agents/linux64-agent2/recipes/396918878/base/src/journaller.cpp(212) writeFileHeader Journaller is not using threaded logging
1462986441.328 <3EBE4700> [WRITE] createMasterDevice id: 03880223 firmware version: 1.0.12 build 106 rev 52752
Please let me know if you have any suggestion for me. I'll be happy to provide you with any other information that might be helpful. Thanks in advance!
Hi!
I just tried to use your node with an MTx IMU with the robot_pose_ekf. The problem is, that the field frame_id is not written to in the imu message however the parameter is set up properly. Therefore the ekf throws warnings (seeing only an empty string in frame_id and assuming the IMU is not running yet).
By adding for example
h.frame_id = self.frame_id
after line 113 in mtnode.py that issue seems to be fixed.
Hi there,
My name is Jorge and I'm totally new in ROS. I've been working with python for a while and I want to get the real-time data from one or two MTw Xsens for a project of my Uni. First, I tried to use the API from Xsens with python but Python is unsupported platform by Xsens so I couldn't. After I found this repository and I guess I can get the real-time data with it but I've never used ROS.
So then, I want to know how to use this repository step by step with ROS and Python. I already read the Package Summary in WikiROS but it's not clear for me.
How can I load the package and the CMakeList in ROS?
How can I run the python code with ROS?
sorry because I know that probably for you those are stupid questions?
Hey,
I've been working with an XSens IMU recently connected via USB, and I'm running into some timestamp jitter issues. Looking through the code, it appears you are using rospy.Time.now() as the message timestamp - so the time the IMU data is received.
On my machine, there is considerable jitter in the received messages. For instance, if I have the IMU set to report at 200hz, if I run:
rostopic hz /imu/data -w 2
I see rates between 190 and 210hz reported. Furthermore, if I record a bunch of data and dump out the timestamps to file, then look at the difference, there is considerable jitter, as well as occasional delays where the next data might not be published for .1 seconds.
To try to fix this, I've begun using the timestamps coming out of the IMU, and simply calculating an offset from the ROS clock so I can publish sync'd to the ROS time stamps. I've pushed this to my fork here (this is just test code, it would need to be cleaned for a PR) https://github.com/jpapon/ethzasl_xsens_driver.git
The problem is, even with this, I'm seeing a continual deviation between the clocks that builds. I got around this by allowing up to .1 seconds of slop, after which the offset resets. In my tests, the clocks were off by about .01 seconds per second - this seems quite large to me.
My main question is - is this jitter normal? Or is it a problem with my USB bus?
Doesn't it make sense to use the XSens time reference, rather than rospy.Time.now()?
Also, any idea if this is caused by using Python? Has there been any work on a C++ version of an XSens ROS node?
Cheers, and thanks!!
Hi,
A small enhancement suggestion. For applications where the IMU might be on a relay, I suggest adding a parameter to specify a small wait time before the node attempts connection to the serial port. This would allow the IMU to be online before the node attempts any config.
Thanks.
It's difficult to aggregate diagnostic messages from mtnode.py since the names do not contain a common prefix. For example:
self.stest_stat = DiagnosticStatus(name='mtnode: Self Test', level=1, message='No status information')
Hi,
Is there a way to use IMU filter madgwick with xsens_driver?
Thanks.
Hey guys,
I am struggling with the configuration of a mti-3. I would like to know if I can tell to the xsens to activate representative motion and ICC otherwise the reading is not consistent. Furthermore I would like to deactivate AHS.
Thanks
I found some bugs in mtdevice when I tried to run it with my MTi. I fixed them here: bhitov@7660fff#xsens_driver/nodes/mtdevice.py
Hi,
there is something wrong
i run the following command and got IndexError: string index out of range
,
./mtdevice.py --echo --device=/dev/ttyUSB0 --output-mode=o --output-settings=q
Full stack traceback:
Traceback (most recent call last):
File "./mtdevice.py", line 1124, in <module>
main()
File "./mtdevice.py", line 1017, in main
print mt.read_measurement(mode, settings)
File "./mtdevice.py", line 400, in read_measurement
return self.parse_MTData2(data)
File "./mtdevice.py", line 591, in parse_MTData2
data = data[3+size]
IndexError: string index out of range
I don't know what data is storing. print data
returns something miss coded string, like
0
>�A�}&Cc�
and the data is different every time.
also roslaunch xsens_driver xsens_driver.launch
return the same thing.
Dev environment is Ubuntu 14.04 kernel 3.19.3 ros indigo
I can run mtmanager to get the roll/pitch/yaw and orientation data.
the following is lsusb -v -d id
result.
Bus 001 Device 008: ID 2639:0003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x2639
idProduct 0x0003
bcdDevice 0.00
iManufacturer 1 Xsens
iProduct 2 MTi-30 AHRS
iSerial 3 0360048E
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
The Xsens IMU allows one to offset the synchronization setting with a negative offset (doc here):
Synchronization settings:
The format follows the xsens protocol documentation. All fields are required
and separated by commas.
Note: The entire synchronization buffer is wiped every time a new one
is set, so it is necessary to specify the settings of multiple
lines at once.
...
Offset:
Offset from event to pulse generation.
100 microseconds unit, range [-30000...+30000]
The struct.pack()
format code in data = b''.join(struct.pack('!BBBBHHHH', *sync_setting)
of:
def SetSyncSettings(self, sync_settings):
"""Set the synchronisation settings (mark IV)"""
self._ensure_config_state()
data = b''.join(struct.pack('!BBBBHHHH', *sync_setting)
for sync_setting in sync_settings)
self.write_ack(MID.SetSyncSettings, data)
in Line 342 of mtdevice.py
. Should the last element not be h
and not H
to allow for a negative number? (format code doc here)
Dear Francis,
I have another issue...it would be awesome if you could help me :-)
When I connect an MTi-G-700 sensor and run:
pi@raspberrypi:~/catkin_ws/src/ethzasl_xsens_driver-master/nodes $ ./mtdevice.py -e
I get the following output:
{'Status': {'StatusWord': 129}, 'Timestamp': {'PacketCounter': 321, 'SampleTimeFine': 64662}, 'Orientation Data': {'Yaw': 0.006209181156009436, 'Pitch': -0.04300256446003914, 'frame': 'ENU', 'Roll': 0.5484659075737}}
{'GNSS': {'numSvs': 11, 'iTOW': 6500, 'svs': [{'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}, {'gnssId': 1, 'cno': 45, 'svId': 147, 'flags': 35}]}, 'Timestamp': {'PacketCounter': 322, 'SampleTimeFine': 2827657820L}}
{'Status': {'StatusWord': 129}, 'Timestamp': {'PacketCounter': 323, 'SampleTimeFine': 64762}, 'Orientation Data': {'Yaw': 0.006437348201870918, 'Pitch': -0.04260209575295448, 'frame': 'ENU', 'Roll': 0.5487979650497437}}
Traceback (most recent call last):
File "./mtdevice.py", line 1704, in
main()
File "./mtdevice.py", line 1470, in main
print mt.read_measurement(mode, settings)
File "./mtdevice.py", line 632, in read_measurement
return self.parse_MTData2(data)
File "./mtdevice.py", line 937, in parse_MTData2
parse_GNSS(data_id, content, ffmt))
File "./mtdevice.py", line 756, in parse_GNSS
content)
ValueError: too many values to unpack
Am I doing something wrong in the settings with the MTmanager? It doesn't matter what I enable with the sensor, it seems to have something to do with the GPS signal or packets...or more precise with the unpacking.
If I run:
pi@raspberrypi:~/catkin_ws/src/ethzasl_xsens_driver-master/nodes $ ./mtdevice.py -b 0 -v -i
Trying 115200 bd: MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 04 5E 04 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 04 5E 00 00 00 00 00 00 00 01 00 01 01 04 05 37 03 00]
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x10 (GoToMeasurement) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x11 (GoToMeasurementAck) with 0 data bytes: []
ok.
MT: Write message id 0x30 (GoToConfig) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x31 (GoToConfigAck) with 0 data bytes: []
MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 04 5E 04 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 04 5E 00 00 00 00 00 00 00 01 00 01 01 04 05 37 03 00]
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: MT: Write message id 0x00 (ReqDID) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x01 (DeviceID) with 4 data bytes: [07 70 04 5E]
0x0770045E
product code: MT: Write message id 0x1C (ReqProductCode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x1D (ProductCode) with 20 data bytes: [4D 54 69 2D 47 2D 37 30 30 2D 32 41 38 47 30 20 20 20 20 20]
'MTi-G-700-2A8G0'
firmware revision: MT: Write message id 0x12 (ReqFWRev) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x13 (FirmwareRev) with 11 data bytes: [01 04 05 00 00 00 55 00 00 C3 C0]
(1, 4, 5)
baudrate: MT: Write message id 0x18 (SetBaudrate) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x19 (SetBaudrateAck) with 1 data bytes: [02]
2
error mode: MT: Write message id 0xDA (SetErrorMode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x42 (Error) with 5 data bytes: [04 00 00 00 00]
message unsupported by your device.
option flags: MT: Write message id 0x48 (SetOptionFlags) with 0 data bytes: []
MT: Got message id 0x42 (Error) with 5 data bytes: [04 00 00 00 00]
message unsupported by your device.
location ID: MT: Write message id 0x84 (SetLocationID) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x85 (SetLocationIDAck) with 2 data bytes: [00 00]
0x0000
transmit delay: MT: Write message id 0xDC (SetTransmitDelay) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x42 (Error) with 5 data bytes: [04 00 00 00 00]
message unsupported by your device.
synchronization settings: MT: Write message id 0x2C (SetSyncSettings) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x2D (SetSyncSettingsAck) with 12 data bytes: [09 01 01 00 00 00 00 00 00 00 00 FA]
[(0x09, 0x01, 0x01, 0x00, 0x0000, 0x0000, 0x0000, 0x00FA)]
general configuration: MT: Write message id 0x0C (ReqConfiguration) with 0 data bytes: []
MT: Got message id 0x0D (Configuration) with 118 data bytes: [07 70 04 5E 04 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 07 70 04 5E 00 00 00 00 00 00 00 01 00 01 01 04 05 37 03 00]
{ 'Master device ID': 124781662,
'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
'device ID': 124781662,
'length': 0,
'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): MT: Write message id 0xC0 (SetOutputConfiguration) with 0 data bytes: []
MT: Got message id 0xC1 (SetOutputConfigurationAck) with 12 data bytes: [10 20 FF FF 10 60 FF FF 70 10 00 04]
[(0x1020, 65535), (0x1060, 65535), (0x7010, 4)]
string output type: MT: Write message id 0x8E (SetStringOutputType) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x8F (SetStringOutputTypeAck) with 2 data bytes: [00 00]
0
period: MT: Write message id 0x04 (SetPeriod) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x05 (SetPeriodAck) with 2 data bytes: [04 80]
1152
alignment rotation sensor: MT: Write message id 0xEC (SetAlignmentRotation) with 1 data bytes: [00]
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0xED (SetAlignmentRotationAck) with 16 data bytes: [3F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
(1.0, 0.0, 0.0, 0.0)
alignment rotation local: MT: Write message id 0xEC (SetAlignmentRotation) with 1 data bytes: [01]
MT: Got message id 0xED (SetAlignmentRotationAck) with 16 data bytes: [3F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
(1.0, 0.0, 0.0, 0.0)
output mode: MT: Write message id 0xD0 (SetOutputMode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0xD1 (SetOutputModeAck) with 2 data bytes: [00 00]
0x0000
extended output mode: MT: Write message id 0x86 (SetExtOutputMode) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x87 (SetExtOutputModeAck) with 2 data bytes: [00 00]
0x0000
output settings: MT: Write message id 0xD2 (SetOutputSettings) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0xD3 (SetOutputSettingsAck) with 4 data bytes: [00 00 00 01]
0x00000001
GPS coordinates (lat, lon, alt): MT: Write message id 0x6E (SetLatLonAlt) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x6F (SetLatLonAltAck) with 24 data bytes: [40 48 0A DB 60 92 81 D5 40 26 8E 1E B5 31 42 7C 40 83 8D B4 48 EC FC 00]
(48.08481986192388, 11.277578031790874, 625.7130297197727)
available scenarios: MT: Write message id 0x62 (ReqAvailableScenarios) with 0 data bytes: []
MT: Got message id 0x63 (AvailableScenarios) with 110 data bytes: [01 07 47 65 6E 65 72 61 6C 20 20 20 20 20 20 20 20 20 20 20 20 20 02 07 47 65 6E 65 72 61 6C 4E 6F 42 61 72 6F 20 20 20 20 20 20 20 03 07 47 65 6E 65 72 61 6C 4D 61 67 20 20 20 20 20 20 20 20 20 20 04 07 41 75 74 6F 6D 6F 74 69 76 65 20 20 20 20 20 20 20 20 20 20 05 07 41 75 74 6F 55 72 62 61 6E 43 61 6E 79 6F 6E 20 20 20 20 20]
[ (1, 7, 'General'),
(2, 7, 'GeneralNoBaro'),
(3, 7, 'GeneralMag'),
(4, 7, 'Automotive'),
(5, 7, 'AutoUrbanCanyon')]
current scenario ID: MT: Write message id 0x64 (SetCurrentScenario) with 0 data bytes: []
MT: Got message id 0x65 (SetCurrentScenarioAck) with 2 data bytes: [00 01]
1
UTC time: MT: Write message id 0x60 (SetUTCTime) with 0 data bytes: []
waiting for 1 bytes, got 0 so far: []
MT: Got message id 0x61 (UTCTime) with 12 data bytes: [1F 58 98 E0 07 E1 02 1B 0A 04 1A 00]
(525900000, 2017, 2, 27, 10, 4, 26, 0)
This looks fine for me ...
So when running this node, I want both the Euler and Quaternion angles, so within the function starting at Ln 297 and the again at Ln 421 I wanted to include:
roll, pitch, yaw = euler_from_quaternion(
degree(orient_data['x']), degree(orient_data['y']),
degree(orient_data['z']), degree(orient_data['w'])
After if/else and try/except, but syntax errors for the next function keep appearing.
File "mtnode.py", line 322
def fill_from_Auxiliary(aux_data):
^
SyntaxError: invalid syntax
Any ideas how I can get both Euler and Quaternion?
Hello,
Is there plan to add commands for setting the synchronization settings of the IV generation devices?
If there is no plan in the near future and I wish to contribute, is it better to start the discussion here or through email?
Regards,
Juichung Kuo
Hello,
I have build your driver for imu data logging to have ROS timestamp along with stereo images
Since we are researching visual inertial odometry algorithm, timestamps on images and imu data are crucial.
Also we are using Mti-g 3rd generation legacy sensor,
https://www.xsens.com/products/mti-g/
When I draw timestamp rosbagged by Xsens_driver at 115200 bps, it shows like stairs, so I plotted delta t (interval between two adjacent timestamps), it shows substantial delay at every 7th data, but with coarsely correct number of samples per second. Below figure shows delta t at 100 Hz sampling rate and it should shows 0.01 second ideally.
It does not have any help with different sampling time setting, for example when I set sampling time as 12Hz then at every 5th sample, it showed delayed timestamp.
I think it is similar to jpapon's "Timestamp jitter" issue, and I tried some remedies you recommended, but still unsolved.
Could you give me some advice for the problem ?
Thanks in advance.
I have a problem similar to this one. I configured my device with rosrun xsens_driver mtdevice.py -c pl,pa,oq,aa,gu,iu,vv,ns,tt
so I'd expect the GPS position in the fix topic in addition to temperature, imu data and a time reference.
I get the following rostopic list:
/imu/data /imu_data_str /rosout /rosout_agg /temperature /time_reference
but no /fix.
The following is the output of rosrun xsens_driver mtdevice.py -i:
Device: /dev/ttyUSB0 at 115200 Bd:
device ID: 0x077001B1
product code: 'MTi-G-700-2A5G4'
firmware revision: (1, 3, 1)
baudrate: 2
error mode: message unsupported by your device.
option flags: message unsupported by your device.
location ID: 0x0000
transmit delay: message unsupported by your device.
synchronization settings: [(0x09, 0x01, 0x01, 0x00, 0x0000, 0x0000, 0x0000, 0x00FA)]
general configuration: { 'Master device ID': 124780977,
'date': '\x00\x00\x00\x00\x00\x00\x00\x00',
'device ID': 124780977,
'length': 0,
'number of devices': 1,
'output-mode': 4,
'output-settings': 1,
'period': 1152,
'skipfactor': 0,
'time': '\x00\x00\x00\x00\x00\x00\x00\x00'}
output configuration (mark IV devices): [(0x5040, 400), (0x5020, 400), (0x2010, 400), (0x4020, 400), (0x8880, 4), (0x1010, 65535), (0xD010, 400), (0x7020, 65535), (0x0810, 1)]
string output type: message unsupported by your device.
period: 1152
alignment rotation sensor: message unsupported by your device.
alignment rotation local: message unsupported by your device.
output mode: 0x0004
extended output mode: 0x0000
output settings: 0x00000001
GPS coordinates (lat, lon, alt): (48.090746326178206, 11.648389707186944, 618.7559459684417)
available scenarios: [ (1, 4, 'General'),
(2, 4, 'GeneralNoBaro'),
(3, 4, 'GeneralMag'),
(4, 4, 'Automotive'),
(5, 4, 'AutoUrbanCanyon')]
current scenario ID: 1
UTC time: (327200000, 1970, 1, 1, 1, 13, 37, 0)
Is there anything unusual in the output or am I configuring the device in the wrong way?
Thanks a lot in advance!
Are you interested in adding urdf description of the xsens mainly for simulation purpose with gazebo ?
We could move the actual files in a directory named xsens_driver
and create a xsens_description
pkg aside.
Hello,
I wanted to implement xsens ros driver in C++. What is the basic idea to proceed and how to make it ?
Hello everyone.
For autonomous vehicle project, I am planning to by MTi-30 AHRS.
On http://wiki.ros.org/xsens_driver says: "This package provides a driver for the third and fourth generation..."
Do this ROS driver supports 5 th generation of Xsens sensors?
Thank you.
Hello
Is this package compatible with MTi-1 Series 3D Module, Link below:
https://www.digikey.com/product-detail/en/xsens-technologies-bv/MTI-3-DK/MTI-3-DK-ND/5325385
I have configured MTI 10 to send sync out signal, and checked using oscilloscope that it indeed does it correctly. However I am unable to find a way to detect in which message sent by the driver to ros did the sync occur. Is this possible and if yes, could you please explain how?
Hi Dear,
I have a problem with ROS Xsens dirver.
As shown in the attached files, When I parsed the GPSSOL data from MTi-G-700, the data length is 52 byte which is not corresponding to the data length in MT Low-Level Communication Protocol Documentation. So I add the 'xxx' in the parsing code. Then I obtained the ECEF position.
However the other data such as ECEF velocity, position accuracy, etc.
I hope you to help me to get the whole data from GPSSOL message.
additionally, I want to know the mean of 'x' in the function "struct.unpack()
Thanks for your help.
Hi, to create a inpuit file for the magnetic field mapper I needed to change mtdef.py and mtdevice.py in the following manner:
mtdef.py:
It would be fine if these changes could be integrated into the driver code. I append the corrected files.
Hi,
I'm using robot localization and was wondering if the drier follows REP 105 standards, in particular, can I assume
all heading data to start with its zero point facing east?
found in robot_localization docs
Thanks
In my current project, I have to use a Raspberry Pi 3 (RPi) with the Raspbian OS (version: jessie). Also some Xsens MTw2 sensors (up to 6) have to be connected to the RPi and the goal will be to record all sensor data to a SD card.
At first I tried to use predefined software from Xsens, such as the MT Manager, the Xsens Device API and accompanying example code. But, it turned out that it is not possible to use this on the RPi, because of the ARM architecture (but the sensors have full Linux support according to the Xsens homepage!).
That's why I started to use ROS with some Node xsens_mti_ros_node-master, which is supposed to work. The node provided by Xsens does not work with the MTw2 sensors, though!
Then I was happy to find the original author/maintainer of the ROS Node.
Starting the node and calling the config of the MTw2 sensor as follows, seems to work - more or less - with the MTw2 sensor, but the inspection stops there and we don't get the full configuration:
$ roslaunch src/ethzasl_xsens_driver-master/launch/xsens_driver.launch
and then:
$ ./mtdevice.py -b 0 -v -i
The output from the MTi compared to the MTw suggests that something is wrong (see attatchment).
MTi MTw.docx
Update: Changing the .launch file to:
xsens_driver_2.zip
works with 2 MTw2 sensors.
Great work with the driver/wrapper. Many thanks!
Hello,
I am using the Xsense MTi-30 both with ROS kinetic and Ubuntu 16.04 and ROS indigo and 14.04. The data obtained looked correct but when I visualized them with rqt-plot I found a strange behavior in the output (screnschot attached). Has someone already dealt with this problem?
Firmware: 1.7.2 build 42 rev 64903 Hardware: 2.1.0
Hello Francis,
With the latest changes, the driver starts to output measurements in the terminal.
I assume it was not intentional.
the print statements are at line 596 and 597 of mynode.py
Hi,
I plugged mti10 my computer, ubuntu 12.04, ros groovy. I run rosrun xsens_driver mtdevice.py.
firstly run output is :
invalid checksum; discarding data and waiting for next message.
MT error: Ack (0x31) expected, MID 0x32 received instead (after 10 tries).
secondly and others run output is:
akay@akay:~/Desktop/xsens_mt-pre3.5$ rosrun xsens_driver mtdevice.py
MT error 0x04: Invalid message.MT error: timeout waiting for message.
whats my fault?
thanks.
rosrun xsens_driver mtdevice.py
is ok!
i already sudo chmod 777 /dev/ttyUSB0
ls -l /dev/ttyUSB0
crwxrwxrwx 1 root dialout 188, 0 8月 27 20:17 /dev/ttyUSB0
but
rosrun xsens_driver mtnode.py
is show erro:could not find proper MT device.
why?
Hi fcolas,
Thanks for sharing this node, however, I too have encountered similar problems using the node.
I am running ROS Fuerte on Ubuntu 12.04, trying to connect to the XSens MTx system. The receivers are connected on /dev/ttyUSB0 and /dev/ttyUSB1.
I notice that the node fails in 'ReqConfiguration()' when it tries to perform 'struct.unpack('!IHHHHI8s8s32x32xHIHHI8x', config)' as the expected message length differs from the one received.
struct.calcsize('!IHHHHI8s8s32x32xHIHHI8x') = 118
struct.unpack('!IHHHHI8s8s32x32xHIHHI8x', config) = 198 and 218
I also notice that 'find_baudrate()' appears to not loop through the different baudrates. Setting baudrate to '921600' enables some communication as 'GoToConfig()' works.
Launching 'mtdevice.py' doesn't work. I get 'MT error: timeout waiting for message.'.
Thanks for looking into this issue!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.