Member #448032

Member Since: June 19, 2013

Country: United States

  • Hi: We got one of these lidar-lite units this week and have been playing with it for an application in a FIRST robot.

    PROS:
    1) It is a dandy little gizmo, and seems quite accurate for at least 0.5 m to at least 20 m (all we have really tested or needed).
    2) Responds quickly!
    3) Light (as in grams). Could be forward-facing or mounted on a little stepper to sweep an arc.
    4) Looks well-built. 5) Darned good price point for the specs. (compare at $1000-5000).

    CONS:
    A) Can be locked-up on close ranging (eg: moving your hand towards it), BUT they have a firmware update as of mid-Jan 2015 to fix it and you can also reset it via software if the lockup happens (cycle pin-2 enable) -- I am not complaining as this is indeed breaking-ground-price-point for this lidar technology, and being a new project, well, stuff happens. They have fixed it for new units, old units can be sent back for a firmware update, and you can detect the issue and reset if necessary, so fwiw. Still cool stuff. B) The pinout could be better. The supplied cable has a red wire for pin 1 (VDD) and black wires for the rest, but not interleaved ground and power to keep electromagnetic crap down (which has been a consideration for everything I have done for about 30 years now). I2C can be a nasty EMI radiation/susceptibility case, so for the lidar-lite I recommend that you twist pin 4 (SCL) with pin 6 (GND), twist pin 1 (VDD) with pin 5 (SDA), and just for symmetry you could twist the non-critical pins 2 (EN) and 3 (MODE) together. Since five of those wires are black, you need to mark them before you twist or you have no idea what is what. It is a really good idea to contain the emi antenna loops from SCL and SDA, and it is generally done using alternating GND/VDD lines in a ribbon cable. Well, except seeed, who also has it goofed up. Anyway, this lidar-lite cable lets you twist wires separately, so just go do that and be happy. Not a big deal, but something that an old gray-haired fart like me would do in a design to minimize potential problems.

    <rant> INTEGRATING INTO 2015 FIRST ROBORIO: This is a specific use-case issue, as we have been unable to talk to simple I2C devices using the on-board roborio I2C port. Others have said that the onboard I2C port is problematic, though the MXP expansion I2C port is fine, however, FIRST rules require an approved "active" expansion board on the MXP port, so that is also a hassle. We may add a RIOduindo board to circumvent the overly-paranoid first mxp rules, but we still need to talk to that board from roborio. Since we are using C++ (and not java, or the goofy visual-programming vi stuff), we have no example roborio code on which to base an I2C design, despite having very good familiarity with low-level i2c-start/write/read/stop functionality, which seems to be abstracted to a level even more obscure than that done in the arduino wire lib. It is all very frustrating -- if anyone feels the pain through which we are going, and has a helpful hint or two to poke us in the right direction, we would be most in your debt. Sheesh, all we really need is some example code to talk from the roborio c++ to an i2c slave by writing and reading various bytes of our choosing, and we can easily do the rest of the slave code. The WPILib interface seems so very bizarre and is closed-source afaik, so we cannot just grab an i2c interface to a simple accelerometer or something and tweak it. Quite a bummer and very few weeks left in the competition. </rant>

    Anyway, pardon the rant -- it is a great unit, but we are just having trouble integrating it into a specific platform. It is well-documented for general applications. If anyone is in the same FIRST quandry, well, let's talk.

    SUMMARY: This is a very-cool little gizmo, even with a few first-gen issues -- love it!

    thx, gil

No public wish lists :(