Roboclaw Reading Issue

[Rafcin]

So I noticed the roboclaw has some problems when it reads data, I get the error
terminate called after throwing an instance of 'boost::system::system_error' what(): Error while reading: Success
I think its due to the encoders, with other Roboclaw nodes I had a similar Input output error, I think its due to encoders but i'm unsure. Are there any specific configurations that should be set on the Roboclaw?

[Rafcin]

It could be a velocity value problem.

[csvance]

How are your encoders configured? This node was created with quadrature encoders in mind, which is a pretty typical setup for differential drive robots. I think its also the default, regardless of PID settings or anything like that.

Also I have seen various version of the RoboClaw firmware not behave correctly according to their published specifications. Try updating to the latest if possible.

[Rafcin]

I am using quadrature encoders, so all the other Python nodes complain that its an issue with 2.7 and its serial communication but this node isn't python so i'm wondering what causes your node to do this. I use the teleop joynode for a few seconds and can move it for roughly 5-10 seconds and then it closes with that error.

[csvance]

If it runs for a time then stops working, it's possible that there is some kind of electrical noise / connection issue interfering with UART communication if you have similar issues with other nodes. Just to be clear, is it just this node that does that, or do other nodes do it as well? If other nodes do as well, it would definitely be worth hooking it up to an oscilloscope/logical analyzer and taking a look at the signal. Regards, Carroll Vance https://csvance.github.io

…

On Mar 16, 2019, at 7:03 PM, Raf ***@***.***> wrote: I am using quadrature encoders, so all the other Python nodes complain that its an issue with 2.7 and its serial communication but this node isn't python so i'm wondering what causes your node to do this. I use the teleop joynode for a few seconds and can move it for roughly 5-10 seconds and then it closes with that error. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGfWaPUdR3Ik3Vdqyk3unFscSGd0DN2wks5vXYZPgaJpZM4b3jwJ>.

[Rafcin]

Yea ill use the schools oscilloscope monday to check, the weird thing its happening with 2 roboclaws that never had this issue. It could also be a issue with the system i'm using a Jetson Xavier so it could be an issue with that. Currently i'm building a Ros Melodic workspace with Python 3 to see if the issue will pass after upgrading to py3 so we'll see. In IonStudio the roboclaw seems to work fine, encoders values are normal.

[csvance]

I personally have not tested the node with more than one Roboclaw as I only currently have access to one. So it could be something specific to that which is causing the problem (this is a supported use case though, waiting on some hardware to be finished before I can test it) I would definitely be interested in seeing an oscilloscope or analyzer capture just before the node crashes. I suspect there is some sort of timing issue. Increasing the timeout in roboclaw_driver.cpp at line 37 might be worth trying, but 200ms (the current timeout) is a long time. Another thing to try is increasing the baud rate (it was tested at 115200) Regards, Carroll Vance https://csvance.github.io

…

On Mar 16, 2019, at 7:43 PM, Raf ***@***.***> wrote: Yea ill use the schools oscilloscope monday to check, the weird thing its happening with 2 roboclaws that never had this issue. It could also be a issue with the system i'm using a Jetson Xavier so it could be an issue with that. Currently i'm building a Ros Melodic workspace with Python 3 to see if the issue will pass after upgrading to py3 so we'll see. In IonStudio the roboclaw seems to work fine, encoders values are normal. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGfWaCgg-sF2B5FDUuFEZ4IJA0Pw7Wbpks5vXY_MgaJpZM4b3jwJ>.

[csvance]

One other thing I thought of, after 5 seconds without receiving any velocity commands roboclaw->set_duty is called for each controller. Could be causing the problem when dealing with more than one node, but code looks correct to me and it worked with one controller just fine.

[Rafcin]

I don't think its an issue of not reviving commands, it happens during input. I could try a different baud rate and check, my work space is almost done compiling so i'll first test the python version of the node and see if it works.

I wonder if the Kernel is missing something specific that causes the error.

[Rafcin]

If it works ill look into then why your node is cancelling out, but seeing as it fails on both devices it could well be a system problem. I'll actually go ahead and test it with Ubuntu Desktop and see if the control works there. Your code seems to be fine so its odd it what causes this.

[Rafcin]

Solved: The USB-C Hub I have is unable to take in info or something but switching to E-Sata USB works.

[Rafcin]

Output*

[csvance]

Interesting. I still am developing with a Jetson TX2 and an older laptop, so I havn't used much USB-C yet.

I will leave this open for now, feel free to respond further or open another ticket.

[Rafcin]

I will test this across a few systems and see how the driver works.