Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeouts and message fragmentation #28

Closed
collinsc opened this issue Jan 19, 2018 · 7 comments
Closed

Timeouts and message fragmentation #28

collinsc opened this issue Jan 19, 2018 · 7 comments

Comments

@collinsc
Copy link

collinsc commented Jan 19, 2018

Hello I have been working with this sensor for a few weeks, and I am running into some synchronization issues with the driver.

I have the device calibrated to:

  • 115200 baud
  • output:
    • orientation: 50hz
    • angular velocity: 50hz
    • linear acceleration: 50hz

Examining the output of the device in mtmanager, the messages are small enough where they fit in a standard message.

The issue I am having is that I need to run the driver at any less than 50hz or it fragments messages like the image below:

screenshot from 2018-01-18 22-00-25

I am in a pretty constrained system, and I don't want to run it that fast, but I do need smooth output from the driver to make our sensor fusion work.

I tried slowing down the publishing rate in the sensor firmware, but what I noticed is that it fragments mti messages into two messages at the device level, which causes the same issue of splitting the data at the driver level.

What I would like to do with the device is run it at ~15 Hz, and have the 3 sets of data output in one message. Is there something I am missing, or something I can modify in the driver/firmware to make this work?

@arunvydhya
Copy link
Contributor

@collinsc give us until the end of the week to get back to you on this. Thanks!

@collinsc
Copy link
Author

No problem! Thanks for the heads up.

@arunvydhya
Copy link
Contributor

We had a detailed look at this and we were not able to reproduce this on our side. We checked the driver logic for the outputs you have chosen and the driver should publish it in a single ROS message - so the issue is quite strange and probably system specific.

We try to keep our driver updated and compatible to our FW changes and make sure that it works with new ROS releases. The primary focus of this driver is to kick-start ROS users in developing their application. In terms of code optimization or platform specific problems that users run into we advise them to look on appropriate ROS community forums for help. I am afraid we are unable to assist you further in this.

@collinsc
Copy link
Author

No problem thanks for looking in to it, if I track down what causes the crash, and it's something that can help others I'll make sure to post it as a response. Thank you.

@arunvydhya
Copy link
Contributor

thanks @collinsc

@dan9thsense
Copy link

dan9thsense commented Feb 27, 2018

I am having a similar problem, where the message output comes in bursts. It seems to be with the serial comm.
imu_serial_stalling
imu_serial_stalling1

@arunvydhya
Copy link
Contributor

Hi @dan9thsense , we do not see this issue with our sensors. It could be a problem with the serial communication layer of the ROS node. To rule out any issues with the sensor, could you please try using the sensor with the Software Suite (MT manager) that is available here - https://www.xsens.com/mt-software-suite/ and see if you can reproduce it. Let us know. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants