Localizing with a LIDAR

[SeanKetring]

Simply put we have a new piece of equipment that we are ordering, and our code base needs to know how to play with it.

This is the lidar that I am going to order:

http://www.ebay.com/itm/Neato-XV-11-12-14-15-21-Signature-Used-Parts-Laser-Distance-Sensor-LIDAR-/171835424667?pt=LH_DefaultDomain_0&hash=item2802307f9b

[SeanKetring]

Introduction

We have a XV-11 LIDAR from the company Neato Electronics. It works by spinning at a rate of 5 Hz and spits out data over Tx and Rx lines at a baud rate of 115200. It reads a distance at every degree to build up a 'picture' of the environment.

The big task is to develop a method of identifying features of the course and accurately place a bot at the location of blocks or shipping zones, as well as navigate between them.

Starting Point::

1) Identifying the version of the XV 11 we have the 5V or 3.3V version.
-Take of the top panel, and read the part number, check online.

2.) Deconstructing the packet by using a serial monitor like an Arduino or Logic Analyzer

Notes

Pinout: Red +5V, or 3.3V
Brown LDS_RX Orange LDS_TX Black GND

Resources

-Helpful site https://xv11hacking.wikispaces.com/LIDAR+Sensor

[ssbagade]

I'll help.

[jasteve4]

https://xv11hacking.wikispaces.com/

Here is a resource to start from

[ssbagade]

https://labviewhacker.com/doku.php?id=projects:lv_neatolds_interface:lv_neatolds_interface

[jmrodri3]

I'll help too

[Sfavorite23]

same

[deepakiam]

me too

[SeanKetring]

Saw yesterday at hackday that the LIDAR we have is spitting out data and currently two devs are working on parsing the data on a BeagleBone. I'm hoping that one of them can update this issue with their current progress!

[tvbarnette999]

We have received data packets from the LIDAR, and done a minimal amount of parsing the packets, but not enough to evaluate the data yet. We ran into issues getting the BeagleBone connected to the internet (and thus to git), so that is where we will be working next time. We were running the motor off a DC power supply separate from the BeagleBone, and it was drawing about 60mA. As far as we can tell, there is no data we have to transfer to the LIDAR, so the RX on the LIDAR is not needed. We have the 5V model, but it works when supplied 3v3 or 5V, both transmitting data at 3v3 logic-levels. Our next steps are getting the BB we were using on the internet, enabling UART1 at boot, and then finish parsing the data to evaluate what we're getting from it.

[tvbarnette999]

We have parsed some of the data we receive from the LIDAR, and are getting good distance data. However, many of the data packets are bad, so we need to try to find what rotational speed maximizes the number of usable packets we receive. We also need to look again at the checksum algorithm, as all of the packets fail.

[AhmedSamara]

@tvbarnette999

What do you guys think of how the Lidar should be powered? Our options right now are:

• Directly to power (assuming we can provide the correct voltage)
  • easy wiring
  • Waste of power/current-draw when we're not using the lidar.
• H-bridge to GPIO or PWM
  • on-off states only
  • PWM only if you think we might need to vary the speed dynamically.

[PaladinEng]

Directly to power. Note that if the lidar is not spinning at the right rpm, it will return invalid data. (On the XV11)

Sent from my iPhone

On Jan 6, 2016, at 12:49 AM, Ahmed Samara notifications@github.com wrote:

@tvbarnette999

What do you guys think of how the Lidar should be powered? Our options right now are:

Directly to power (assuming we can provide the correct voltage) easy wiring Waste of power/current-draw when we're not using the lidar. H-bridge to GPIO or PWM on-off states only PWM only if you think we might need to vary the speed dynamically. — Reply to this email directly or view it on GitHub.

[AhmedSamara]

My thought was that if we find that it's sending back invalid/corrupted data, we can use the PWM to adjust until it's correct (if voltage stability ever becomes an issue).

The GPIO would also be good for shutting it off just so that we don't have that moving part and don't put too much stress on the power system by constantly drawing current.

[adwiii]

I don't know when there would be a time when you would want to turn off the LIDAR since we need to actively track position while we moves. It's only 60 mA, so leaving it on shouldn't be that much of a problem for the power system. I also don't think we will need to change the voltage from what we find to be the peak, so unless we think it's going to be of real concern maintaining that voltage, then we should be able to just hardwire it and have it be always on.

On Wed, Jan 6, 2016, 5:46 PM Ahmed Samara notifications@github.com wrote:

My thought was that if we find that it's sending back invalid/corrupted data, we can use the PWM to adjust until it's correct (if voltage stability ever becomes an issue).

The GPIO would also be good for shutting it off just so that we don't have that moving part and don't put too much stress on the power system by constantly drawing current.

— Reply to this email directly or view it on GitHub https://github.com/IEEERobotics/bot/issues/372#issuecomment-169486607.

[PaladinEng]

Plus, the team needs to weigh the risk/benefits. PWM may be an unnecessary complication when simply selecting the right resistor will work just as well (in general) and take a lot less time.

On Wed, Jan 6, 2016 at 5:54 PM, Trey Woodlief notifications@github.com wrote:

I don't know when there would be a time when you would want to turn off the LIDAR since we need to actively track position while we moves. It's only 60 mA, so leaving it on shouldn't be that much of a problem for the power system. I also don't think we will need to change the voltage from what we find to be the peak, so unless we think it's going to be of real concern maintaining that voltage, then we should be able to just hardwire it and have it be always on.

On Wed, Jan 6, 2016, 5:46 PM Ahmed Samara notifications@github.com wrote:

My thought was that if we find that it's sending back invalid/corrupted data, we can use the PWM to adjust until it's correct (if voltage stability ever becomes an issue).

The GPIO would also be good for shutting it off just so that we don't have that moving part and don't put too much stress on the power system by constantly drawing current.

— Reply to this email directly or view it on GitHub https://github.com/IEEERobotics/bot/issues/372#issuecomment-169486607.

— Reply to this email directly or view it on GitHub https://github.com/IEEERobotics/bot/issues/372#issuecomment-169488340.

[AhmedSamara]

My worry was just crossing off our options for later.
If we attach it to a PWM/GPIO we can always just leave them as always on, and if we find out later we have a reason to slow it down or turn it off we can.