XV-11 LIDAR error codes

[jsam...@pobox.com]

Does anybody know the definition of the error codes for the XV-11 LIDAR?

This page  https://xv11hacking.wikispaces.com/LIDAR+Sensor says:

  "When bit 7 of byte 1 is set, it indicates that the distance could not be calculated. When this bit is set, it seems that byte 0 contains an error code. Examples of error code are 0x02, 0x03, 0x21, 0x25, 0x35 or 0x50..."

But I haven't a list of what these codes are.

- Jeff Sampson

[Nathan Monson]

I don't think Neato ever documented the Lidar's binary UART protocol, but they did document an ASCII version, accessible via the USB port:

https://www.neatorobotics.com/resources/programmersmanual_20140305.pdf

The complete list of errors are as follows (taken from the doc above):

LS_LDS_DotTooWide

LS_LDS_DoubleDot

LS_LDS_TooNear

LS_LDS_OutOfCal

LS_LDS_TooFar

LS_LDS_TooDim

LS_LDS_NoReading

LS_LDS_TooSlow

LS_LDS_EncoderSkip

LS_LDS_DumbPanavision

LS_LDS_SunBlind

LS_LDS_NoDot

LS_LDS_BadArg

LS_LDS_NoMatch

LS_LDS_Abort

LS_LDS_Escape

LS_LDS_LaserCharging

LS_LDS_LaserPhotoTrip

LS_LDS_LaserEncoderTrip

LS_LDS_LaserClockTrip

LS_LDS_LaserDebugTrip

LS_LDS_LaserOverCurrent

LS_LDS_LaserOverPWM

LS_LDS_LaserPhotoStuck

LS_LDS_LaserCurrentStuck

LS_LDS_LaserOverTemp

LS_LDS_LaserFlakyPhoto

LS_LDS_LaserFlakyCurrent

LS_LDS_ReservedCode

I'm not sure if their order in the doc corresponds to their actual numeric order or not.  A patient hacker could hook a UART to a Neato mainboard and "spoof" numeric error codes in to see which ASCII names come out.

I'm not aware of any hackers who have done this yet.

Nathan

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at https://groups.google.com/group/hbrobotics.
For more options, visit https://groups.google.com/d/optout.

[jsam...@pobox.com]

Thanks, that is a much larger list than I expected. I don't have the Neato robot so I can't do the comparison. Although this guy has code to do that [LDSErrorSpoofer]:

https://github.com/Xevel/NXV11

So I will probably set up the LIDAR and try to force the errors. Too near, too far, backlit, reflective, absorbtive...

It just seemed that these have been out long enough that someone would have figured out these codes.

- Jeff Sampson

---

From: Nathan Monson <nmo...@gmail.com>
To: hbrob...@googlegroups.com
Sent: Sunday, April 24, 2016 7:31 PM
Subject: Re: [HBRobotics] XV-11 LIDAR error codes

[James LeRoy]

I'm curious what you intend to do with the specific error codes?  For me I figure that as long as I know there's an error, I just discard it and don't worry about going too much into analyzing the error.  Especially with a moving robot where the errors are constantly changing.

[jsam...@pobox.com]

I want to make the XV-11 work more like the industrial scanners that ROS was designed around. Specifically I don't think that every error condition should equate to a distance of 0. Possibly a "too near" indication should equate to 0. But it seems that a "too far" error should translate to some maximum distance.

If I get a chance Wednesday night I will set up my SICK LMS200 at the local Makerspace and see what it puts out in the "too near" and "too far" conditions. Or I could set it up in my front yard to produce a max range condition.

Since it appears that ROS local costmap is relying on a "maximum range" indication. Or more specifically a value of less than "raytrace range" to perform clearing, then it seems that you don't want to report a range of zero instead of a "too far" indication.

So I am just trying to get a better understanding of what the XV-11 LIDAR puts out and how to better use the information.

And specifically I'm trying to fix the problem described here:

http://ros-users.122217.n3.nabble.com/Clearing-old-obstacles-from-costmap-td1920291.html

http://ros-users.122217.n3.nabble.com/Clear-cells-in-costmap-with-max-laser-range-td973150.html

So the laser has to return the difference between "too near" and "too far" and then apply a laser filter to set a value higher than "raytrace range" to less than or equal to "raytrace range". If it always returns 0 for any out of range (or any other error) then it doesn't work, as far as I can see.

- Jeff Sampson

---

From: James LeRoy <ja...@getsurreal.com>
To: hbrob...@googlegroups.com
Sent: Monday, April 25, 2016 11:45 AM

Subject: Re: [HBRobotics] XV-11 LIDAR error codes

[Patrick Goebel]

Hi Jeff,

Not sure if you have already looked at this, but the hokuyo.cpp file from the hokuyo_node package has some nicely labeled error conditions and what range values are returned for each.  Take a look at the code starting at line 538 (indigo-devel branch).  The two most common values returned for an error condition appear to be infinity() and quiet_NaN().

If you use infinity, you might be able to use the inf_is_valid parameter in your costmap config file to allow such values to clear obstacles.  (See http://wiki.ros.org/costmap_2d/hydro/obstacles and search for inf_is_valid.)

--patrick

-- 
The Pi Robot Project
http://www.pirobot.org/wordpress

[Jeff]

Patrick,

Thanks for the pointer to the Hokuyo code. I didn't know the concept of infinity existed. That would probably be the right way to fix it, if the XV-11 would report valid info. I had seen the reference to the inf_is_valid parameter, but I had no idea what inf stood for. Now I know it stands for infinity, so I know one more secret. :-)

I played with the XV-11 LIDAR some more. I seem to get 0x8035 errors. I get that for "too near" condition and I get that for "too far" condition. Both cases give me a quality (intensity) of 0. I get 0x8003 for a very narrow transition between a minimum distance and "too near" distance. But I don't know what that is trying to tell me. I saw a random 0x8025 but I don't know what caused it. And I haven't seen the 0x8021 error which is reported to show up when the LIDAR see the supports on the cover.

Bottom line is... It doesn't look like the LIDAR reports the difference between the different conditions. So I don't know how they came up with that extensive list of LDS errors that was published. Maybe it results from a special LIDAR test condition? Or maybe you can send extra commands to the LIDAR to report "extra" conditions? But since I don't have the Neato vacuum base I can't snoop any "extra" communication to the LIDAR.

So unless something else turns up I guess I will put up with the data that is being supplied. Or maybe some extra processing could be added to the costmap to clear objects when valid objects are not being reported.

I.e., Objects are indicated in the map but the laser is not reporting an object. But that still leaves the problem of non-reflective objects not reporting as an object...

- Jeff Sampson

--

[Michael Ferguson]

REP 117 (http://www.ros.org/reps/rep-0117.html) defines the "standard" for this sort of thing -- although the XV-11 drivers probably predate the standard, and even some new drivers don't exactly follow the standard.

-Fergs

[Jeff]

Well, the last point I was trying to make was... if the hardware doesn't tell you, then you can't know. As far as I can tell is that if the hardware doesn't distinguish "too far" or "too near"  vs. valid, then you can't magically determine this yourself. (At least at the driver level.)

It would have to be done closer to the costmap level. So you know history of what is known and not known.

But it is good to know that an official statement defines the way it should be done, as long as the hardware provides the information.

So I will continue with my problem of not knowing what actually exists if I am looking into open space.

- Jeff Sampson