Malformed sub-payload detected. #382
Comments
|
I'm facing the same issue, using Intel NUC, it was working fine before! but this error start to show-up recently ! ROS Indigo, |
|
Does it show up continuously or sporadically? Is it an old kobuki? Old cable? |
|
Hi @stonier , It shows up when we execute: roslaunch kobuki_node minimal.launch --screen, and continuously shows up every tens second. I just purchased and received it from Trossen Robotics, don't know if it is old or not, checked the version which shows: Version Info:
First guess is caused by mis-matched data type in communication module of software. -- Luke Detail error msg:
|
|
The only thing that stands out for me (given that software/firmware works in general and has suddenly gone from working to not working) is that noise on the serial connection interferes with the payload. I've seen this happen on serial connections that are long / old / have a great deal of electromagnetic interference. Haven't seen it on a kobuki yet. To debug further, see if you can isolate the problem to the communication line. Some experiments:
|
Thanks for your advice @stonier , do you have any recommended serial communication cable which is short enough and interference free for the test ? In the same time, I'll get few shorter and better usb cable for further testing. -- Luke |
|
Nothing special. You're just chasing some second opinions on the communication problem to verify it isn't the cable that you have that is the source of the problem. Equivalently, the second bullet above is to verify if the FTDI usb-serial io device on the kobuki is the source of the problem. |
|
Note - you shouldn't have a software/firmware mismatch. If there was a major version mismatch, it would immediately abort and if there was a minor version mismatch you'd get a warning on startup. See here. It also wouldn't be sporadic. |
|
Thanks for your prompt reply @stonier BTW, what does "payload" and "sub-payload" in the context mean ? Is it a mechanical fixture to support physical loading or a virtual digits in protocols for communication ? |
|
Each packet carries a variable length chain of data packets depending on what was requested in the last command window. Each sub-payload caries the data for a single quantity (e.g. cliff sensors). You can see details (not great english, but you'll get the idea) here: http://yujinrobot.github.io/kobuki/enAppendixProtocolSpecification.html. If I remember correctly, there might be a rostopic you can tune into to see the full packet (good and bad) stream? |
|
Thanks for your suggestion @stonier -- Luke |
|
@lukelu0520, to rule out another possibility: do you have several USB devices connected to the same hub (or same USB board within the PC) as Kobuki? I noticed with my robot that the number of |
|
I think I fixed this issue! By default the usb latency timer in Linux is set to 16ms for FTDI usb communication. By changing this to the lowest possible value (1ms), this issue disappears! Let me know if this works for you guys and I'll submit a PR to update the udev rules for kobuki. There are a couple ways to change the latency timer. The best approach is to just edit the kobuki udev rule. Mine is located at /lib/udev/rules.d/60-ros-melodic-kobuki-ftdi.rules. Substitute the line with ...
|
|
Oh, looks like the world shifted in linux kernel 4.10 (which was after the initial releases of kobuki) for the ftdi driver. See here and here. That would explain why the problems are occurring now and not when Kobuki was initially released. That udev rule could well work (looking forward to hearing from others), but perhaps a better solution is to do it programatically (see the second link above) so the |
|
A long thread over in Octopi about this: guysoft/OctoPi#566 Interesting to note, if we could pad packets out to multiples of 64bytes, it would fire off the chain of sub-packets with no 16ms delays. Unfortunately we don't have access to the firmware :/ Potentially, some code that could set the low latency flag: However, folks in threads I've read mention that you need root permissions to set that flag :/ |
Correct me if I'm wrong (and there's a good chance I am since I don't really work in serial communication) but it sounds like the latency timer only comes in to play when a 'read' command is sent to a device from a host computer. If no 'read' command is sent, which I imagine would be the case if the Kobuki is just plugged in to the computer but no code is running, then the port wouldn't be spinning at all? |
|
Not an expert either, but looks like you're correct. Reference: FTDI Knowledgebase - Custom Latency Timer Value. Having said that - this looks like the right thing to do, if only to reduce the latencies in reading the packet stream. That still doesn't explain however why the data is malformed at 16ms latencies, I would have expected it to be ok, just slower on the uptake. |
|
For reference, you can determine the configured latency timer on your loaded device with: I can confirm the udev rule above does set it to 1ms. I'm getting some interesting results with stream.cpp: With 16ms latency: With 1ms latency: Conclusions:
I don't seen any negative ramifications due to increasing the polling rate that affects usual use of kobuki. +1 for getting this patch in. |
|
@swinterbotix @stonier , amazing, problem solved after applying your solution. |
|
Released |
|
Do you plan to make version 0.7.9 available on APT for kinetic/melodic? It's still showing 0.7.8 as the most recent version. |
|
http://repositories.ros.org/status_page/ros_melodic_default.html?q=kobuki You'll see that it's still just a release candidate and hasn't yet been pushed to the release servers. You can get early access to it via the ros-testing server, see this wiki page. I didn't release it in kinetic. I can't test it at the moment and there are some changes that might not backport so was cautious about sync'ing branches. If you would like to use it there, and can confirm the udev rule changes in yujinrobot/kobuki_core@45f834c work, I'll cherry-pick that single change and re-release. |
|
I've confirmed that the robot still works even with the updated udev rule. I did this by first installing version 0.7.8 from apt on kinetic, then updating the udev rule in the /lib/udev/rules.d directory with the latency changes. Next, I ran During the couple minutes I was playing with it, I did not see any malformed sub-payload errors. Honestly, the main reason I'd like it offered in kinetic is just for flexibility. The company I work for sells a few dozen kobuki bases as part of our robot platforms, and I'd like to give users the ability to choose between kinetic or melodic. |
|
On it's way in kinetic, melodic & noetic, |
|
Finally regain access to my old, good kobuki; |
update readme, the kobuki working now!
I am running the Turtlebot2 with the Kobuki base. Both on Indigo en Kinetic, I receive the error:
Kobuki: malformed sub-payload detected, ...The sub payload that is shown is always a sub-payload of the base-state as defined by the protocol specification with a lenght of 77 bytes. (
AA 55 4D 01 0F) However, the reported error does not have 77 bytes of data. This does match the behaviour as described in kobuki.cpp line 405 of the kobuki_driver.I have tested this with two laptops running in Indigo and one running on Kinetic, and two different Kobuki bases.
The text was updated successfully, but these errors were encountered: