Serial number, reboot - Githubissues

dogoepp commented 8 years ago

This pull request is a sequel to the #20 on which it does a few improvements:

No need to make an assumption on the port name that Linux will allocate to the sensor. An udev rule takes care of the naming of the sensor ports, based on their serial number
The persistence is no longer at the level of the topic, but the port name
The ROS node is separated from the driver (because we need the driver for the udev rule)
We actually check that the data received matches a frame header, freeing ourselves from the occasional "bad checksum" warning waterfall.

kirstyellis commented 7 years ago

I have tried to test this with an OMD-10 3-axis sensor and it is not working, in dubug mode I am getting the error: I can't recognize a header in this data And the device is not being renamed from /dev/ttyACM0 to optoforce_*

Any suggestions @dogoepp ?

dogoepp commented 7 years ago

Could you copy the frame itself ? It should be the series of numbers after the colon.

kirstyellis commented 7 years ago

Here is a sample: I can't recognize a header in this data: (151,) I can't recognize a header in this data: (255,) I can't recognize a header in this data: (160,) I can't recognize a header in this data: (143,) I can't recognize a header in this data: (67,) I can't recognize a header in this data: (85,) I can't recognize a header in this data: (112,) I can't recognize a header in this data: (107,) I can't recognize a header in this data: (171,) I can't recognize a header in this data: (70,) I can't recognize a header in this data: (123,) I can't recognize a header in this data: (71,) I can't recognize a header in this data: (3,) I can't recognize a header in this data: (68,) I can't recognize a header in this data: (239,) I can't recognize a header in this data: (0,) I can't recognize a header in this data: (159,) I can't recognize a header in this data: (113,) I can't recognize a header in this data: (69,) I can't recognize a header in this data: (113,) I can't recognize a header in this data: (202,) I can't recognize a header in this data: (113,) I can't recognize a header in this data: (165,) I can't recognize a header in this data: (1,) I can't recognize a header in this data: (13,) I can't recognize a header in this data: (10,) I can't recognize a header in this data: (213,) I can't recognize a header in this data: (55,) I can't recognize a header in this data: (68,)

dogoepp commented 7 years ago

I find it very strange. Could you try with the master version of the node ?

Also, how many axes does it have ? Do you have the protocol documentation for this sensor ?

It might be that the frame header detection I made does not match for this sensor, though it would be rather surprising.

kirstyellis commented 7 years ago

It has 3 axes, unfortunately I do not have the protocol documentation for this sensor. Sorry, what do you mean by "try with the master version of the node"?

Thanks

dogoepp commented 7 years ago

With

Sorry, what do you mean by "try with the master version of the node"?

I meant to ask whether this sensor used to work with the previous version of the ROS node (the one in the master branch of this repository).

You get the debug message about header recognition because I store all accepted frame header. If your sensor does not send one of these headers, then its data is not read. I'll see with the guys at OptoForce if I can get the documentation for the OMD-10 (is this the full model name ?)

kirstyellis commented 7 years ago

It does seem that the sensor that I am testing is an old single channel sensor that had a different protocol and also required a special branch. At the moment we have no other sensors that we can use to test these changes and as these changes are quite big and we rely on this code to be working, we would really like to test the changes before we merge. Is it OK if we leave it un-merged for now, we will try to get hold of some sensors and keep you updated when we test.

Thanks!

dogoepp commented 7 years ago

OK, thanks for your efforts reviewing this pull request. I'm looking forward for test results.

In the meantime, I moved our robot to this code. I'll fix here any error that I could find.

dg-shadow commented 7 years ago

Hi. I may be doing something stupid, but when I test this with a 4-channel device, I get

[ERROR] [WallTime: 1480962669.037774] optoforce: Bad checksum in frame: (170, 7, 8, 28, 240, 197, 0, 0, 0, 1, 0, 2, 0, 21, 255, 237, 0, 19, 0, 4, 0, 3)

ad infintum :/ Any ideas as to why?

dogoepp commented 7 years ago

It seems that you make a very valid point. Apparently I made a mistake in the association between frame header and frame length. The software believes that the frames should be 22 bytes long instead of the actual 34.

Please try with fix-frame-length branch. I shall also test again with our four-channel sensor.

shadow-robot / optoforce

Serial number, reboot #23