I made a similar post to this on the Java forum, but now I’m thinking my problem could be electrical because I’ve had no success whatsoever. I’m using a LIDAR Lite v3, connected to the I2C port on a NavX-mxp. Has anyone here had any success? I’m re-reading the datasheet and it says something about putting an electrolytic capacitor between the VCC and GND pins on the Lidar. Is that actually necessary? I read somewhere else that the Lidar needs pull-up resistors, but I also read the roboRIO has them built in. Any help is appreciated!
First I’d try to get it working on the built-in RoboRIO i2c port. You shouldn’t need pullups (the RIO does have them internally iirc), but you will absolutely want a capacitor bridging +5 and ground. ~1000uF and ≥25v tolerance should work fine. Make sure to get the polarity right otherwise things will get explodey.
I thought the built in I2C port only outputs 3.3v instead of 5v. Should I still use that instead?
No, do not use that. The LIDAR lite will only function with 5v power, and, as you said, the RoboRIO only outputs 5v on the MXP, not the onboard I2C. You do, however, have to make sure that the navX has it’s DC voltage jumper in the 5v position.
You can actually plug it in to any of the dio power - they are all 5V.
Be careful on lidar versions and code. V1 will not work with V3 code, and vice versa. So make sure the code you’re using matches your version.
The NavX is set to 5v. Would the missing capacitor affect my inability to communicate with the Lidar? Or should I go back to the programming forum? I thought the capacitor only served to regulate voltage spikes.
We got the Lidar Lite v3 working last year on the I2C bus along with Pixy cams. Just note it worked well on our practice field but not so much in last years competition. Our practice field was mostly plywood, but the real field was a lot of clear plastic. The laser went right through it. Kind of a palm to forehead moment when we figure out what was happening, so just giving a heads up to consider what the target is.
We connected the Lidar Lite to the NavX headers and I see you have already set it to 5 volt. We connected in a capacitor close to the Lidar per the manual. Keep your I2C bus line as short as possible, preferably shielded cable to minimize noise. Only ground the one side of the shield wire.
Here is the code we started with (we program in Java):
In RobotMap:
public static Lidar lidar;
lidar = new Lidar(I2C.Port.kMXP, (byte) 0x62);
Create a new class called Lidar and put this in:
import java.nio.ByteBuffer;
import java.util.TimerTask;
import edu.wpi.first.wpilibj.I2C;
import edu.wpi.first.wpilibj.I2C.Port;
public class Lidar {
private I2C i2c;
private java.util.Timer updater;
private ByteBuffer buffer = ByteBuffer.allocateDirect(3);
private volatile int distance;
private int measurementCount = 0;
private static final int LIDAR_BUSY_MASK = 0x01;
private static final int LIDAR_COMMAND_ACQUIRE_WITHOUT_CORRECTION = 0x03;
private static final int LIDAR_COMMAND_ACQUIRE_WITH_CORRECTION = 0x04;
private static final int LIDAR_CONFIG_REGISTER = 0x00;
private static final int LIDAR_STATUS_REGISTER = 0x01;
private static final int LIDAR_SIG_COUNT = 0x02;
private static final int LIDAR_ACQ_CONFIG = 0x04;
private static final int LIDAR_THRESHOLD_BYPASS = 0x1c;
private static final int LIDAR_DISTANCE_REGISTER = 0x8f;
private static final int UPDATE_PERIOD = 20; // in milliseconds
private static final int RETRY_COUNT = 50;
public Lidar(Port port, byte address) {
i2c = new I2C(port, address);
setup();
updater = new java.util.Timer();
updater.schedule(new TimerTask() {
@Override
public void run() {
distance = getUpdatedDistance();
}
}, 0, UPDATE_PERIOD);
System.out.println("Started");
}
// Distance in cm
public int getDistance() {
return distance;
}
public void setup() {
i2c.write(LIDAR_SIG_COUNT, 0x80);
sleep(1);
i2c.write(LIDAR_ACQ_CONFIG, 0x08);
sleep(1);
i2c.write(LIDAR_THRESHOLD_BYPASS, 0x00);
sleep(1);
}
// Update distance variable
private int getUpdatedDistance() {
int command = (measurementCount % 100 == 0 ? LIDAR_COMMAND_ACQUIRE_WITH_CORRECTION : LIDAR_COMMAND_ACQUIRE_WITHOUT_CORRECTION);
i2c.write(LIDAR_CONFIG_REGISTER, command); // Initiate measurement
/if (measurementCount++ % 50 == 0) {
System.out.println("count = " + measurementCount + ", distance = " + distanceValue);
}/
measurementCount++;
int busyCount = 0;
do {
sleep(1);
int status = readByte(LIDAR_STATUS_REGISTER);
boolean busy = (status & LIDAR_BUSY_MASK) == LIDAR_BUSY_MASK;
if (!busy) {
return readShort(LIDAR_DISTANCE_REGISTER);
} else {
busyCount++;
}
/SmartDashboard.putNumber(“status”, status);
SmartDashboard.putBoolean(“busyFlag”, busy);/
} while (busyCount < RETRY_COUNT);
System.out.println(“Distance read timed out”);
return distance;
}
private void sleep(long millis) {
try { Thread.sleep(millis); } catch (InterruptedException e) { e.printStackTrace(); }
}
private int readByte(int register) {
buffer.put(0, (byte) register);
i2c.writeBulk(buffer, 1);
i2c.readOnly(buffer, 1);
return buffer.get(0) & 0xFF;
}
private int readShort(int register) {
buffer.put(0, (byte) register);
i2c.writeBulk(buffer, 1);
i2c.readOnly(buffer, 2);
return buffer.getShort(0) & 0xFFFF;
}
}
The lidar unit will start up as soon as the RobotMap is initialized.
Use RobotMap.lidar.getDistance() to get the distance value in cm where needed. This should get you started.
Capacitor works as voltage stabilizer, so it must be something else.
Have you used the LIDAR with an Arduino just to test that it is working?
I posted this earlier but must have done something wrong as my post has not shown up.
Marshall brings up a good point. Testing it on an Arduino would let you be sure it is working.
We setup a Lidar Lite v3 and Pixy cams last year using I2C but did not end up using the Lidar after the first competition. Worked great in our plywood practice field but not so well on the clear plastic of the competition field. Lidar goes through clear plastic. Kind of one of those palm to forehead moments, so when you get it working consider what your target is going to be.
We connected the Lidar to the I2C terminals on the the NavX board. We did mount the capacitor close to the Lidar per the instruction manual. Keep the I2C wiring as short as you can and use shielded wire if you have it. We did start off with regular wire, but the shielded wire helps cut down on noise issues we saw on the I2C bus.
Here is code that should get it up and working providing the unit is functional and the wiring is right
In RobotMap:
public static Lidar lidar;
lidar = new Lidar(I2C.Port.kMXP, (byte) 0x62);
Create a new class called Lidar and put this in:
import java.nio.ByteBuffer;
import java.util.TimerTask;
import edu.wpi.first.wpilibj.I2C;
import edu.wpi.first.wpilibj.I2C.Port;
public class Lidar {
private I2C i2c;
private java.util.Timer updater;
private ByteBuffer buffer = ByteBuffer.allocateDirect(3);
private volatile int distance;
private int measurementCount = 0;
private static final int LIDAR_BUSY_MASK = 0x01;
private static final int LIDAR_COMMAND_ACQUIRE_WITHOUT_CORRECTION = 0x03;
private static final int LIDAR_COMMAND_ACQUIRE_WITH_CORRECTION = 0x04;
private static final int LIDAR_CONFIG_REGISTER = 0x00;
private static final int LIDAR_STATUS_REGISTER = 0x01;
private static final int LIDAR_SIG_COUNT = 0x02;
private static final int LIDAR_ACQ_CONFIG = 0x04;
private static final int LIDAR_THRESHOLD_BYPASS = 0x1c;
private static final int LIDAR_DISTANCE_REGISTER = 0x8f;
private static final int UPDATE_PERIOD = 20; // in milliseconds
private static final int RETRY_COUNT = 50;
public Lidar(Port port, byte address) {
i2c = new I2C(port, address);
setup();
updater = new java.util.Timer();
updater.schedule(new TimerTask() {
@Override
public void run() {
distance = getUpdatedDistance();
}
}, 0, UPDATE_PERIOD);
System.out.println("Started");
}
// Distance in cm
public int getDistance() {
return distance;
}
public void setup() {
i2c.write(LIDAR_SIG_COUNT, 0x80);
sleep(1);
i2c.write(LIDAR_ACQ_CONFIG, 0x08);
sleep(1);
i2c.write(LIDAR_THRESHOLD_BYPASS, 0x00);
sleep(1);
}
// Update distance variable
private int getUpdatedDistance() {
int command = (measurementCount % 100 == 0 ? LIDAR_COMMAND_ACQUIRE_WITH_CORRECTION : LIDAR_COMMAND_ACQUIRE_WITHOUT_CORRECTION);
i2c.write(LIDAR_CONFIG_REGISTER, command); // Initiate measurement
/*if (measurementCount++ % 50 == 0) {
System.out.println("count = " + measurementCount + ", distance = " + distanceValue);
}*/
measurementCount++;
int busyCount = 0;
do {
sleep(1);
int status = readByte(LIDAR_STATUS_REGISTER);
boolean busy = (status & LIDAR_BUSY_MASK) == LIDAR_BUSY_MASK;
if (!busy) {
return readShort(LIDAR_DISTANCE_REGISTER);
} else {
busyCount++;
}
/*SmartDashboard.putNumber("status", status);
SmartDashboard.putBoolean("busyFlag", busy);*/
} while (busyCount < RETRY_COUNT);
System.out.println("Distance read timed out");
return distance;
}
private void sleep(long millis) {
try { Thread.sleep(millis); } catch (InterruptedException e) { e.printStackTrace(); }
}
private int readByte(int register) {
buffer.put(0, (byte) register);
i2c.writeBulk(buffer, 1);
i2c.readOnly(buffer, 1);
return buffer.get(0) & 0xFF;
}
private int readShort(int register) {
buffer.put(0, (byte) register);
i2c.writeBulk(buffer, 1);
i2c.readOnly(buffer, 2);
return buffer.getShort(0) & 0xFFFF;
}
}
Assuming wiring is correct and the Lidar is functional the Lidar unit will start up when the Robot is initialized. Use RobotMap.lidar.getDistance() to get the distance in cm.
This should get you started.
1 Like
How would I get it to work with an iterative robot? And how much of a deal is I2C noise? When I get home I’m going to work on getting my Arduino board to work with it.
If you have $200, here’s a great way to spend it that can help answer your question. https://www.amazon.com/Saleae-4-Channel-Logic-Analyzer/dp/B018RE3OTY/ref=sr_1_4?ie=UTF8&qid=1514245975&sr=8-4&keywords=Saleae. It’s a seriously beautiful product and very helpful for debugging comm protocols like i2c, spi and uart.
Alternatively, an oscilloscope can show you the signal quality, although it won’t decode the protocol for you.
Generally, be sure to avoid running i2c wires near motors, research i2c wire length guidance, and review if running at the slower speed (100khz) is viable, as that will be somewhat less sensitive to noise than fast mode (400khz).
To run in Iterative robot you would still need to create the Lidar class and insert the code. You would put the items from the Robotmap section in the area where you initialize your robot. You would then call lidar.getDistance() where you need the distance value.
The noise on the line can be an issue. Last year our main Pixy camera and the Lidar ended up about as far away from the roborio as was possible making controlling noise difficult. It was literally placed diagonally across the robot from the roborio both horizontally and vertically. This caused our lines to be longer then they should have been. Still well within limits for I2C but longer then we would have preferred. They also had to go around several power wires, Talons, and were right over two motors for our right front drive. On our particular bot the worst noise offender seemed to be our 775pro powered shooter which happened to have a second pixy camera located near it, also on the I2C bus. Like I said earlier, changing over to shielded wire helped. You should note that we only ground one end of the shield wire, in our case the end closest to the roborio to prevent weird loops in the shield. We still did have occasional issues though where the I2C bus would lock up. What we found was that the I2C line would hang with the one line held high indefinitely. We believe that the noise from the motor(s) would occasionally trigger a spike on the I2C bus that made the bus think there was another I2C master on the line. Being that I2C is a multi-master multi-slave system the roborio master would then simply wait for the new master to complete it’s transmission which of course is never going to happen. We never did put a scope on the line to confirm this, but every time it occurred a digital logic probe showed the lines stuck in the same manner that seemed to indicate the transmission was waiting for completion. Now mind our theory on this could be wrong and if anyone else has better info or a better theory on the lock up problem we would be glad to hear it. In the end we did find that if we forced the line that was held high to a low state it and then released it the bus would restart. It should be noted that the I2C bus on the Roborio is a software controlled bus using two special DIO pins. On the MXP board they are DIO pins 24 and 25. What our one programming mentor did was to write a library file for the Roborio at the roborio level allowing us to selectively switch MXP pins 24 and 25 from I2C mode to DIO mode and back. By doing this we were able to track when an “event” occurred, switch modes to allow us to control the pins to reset the bus, and then switch the pins back into I2C mode to continue operations. Like I said this did not happen often after changing over to good wire, but we wanted to be sure it would never be a problem.
The following links are for the code we ended the season with. It is very similar to the code above but it adds in the ability to reset the bus as described. Just note that installing this takes a bit more effort then the code listed previously.
I have put our last years code on github. The fault correction for the I2C bus is here https://github.com/Cybersonics/MXPSpecial/tree/master/libmxp_specialness.
To install this copy the four files there and follow the directions in the readme file. Just remember to change the team number following roborio- to your team number. What you will be doing is installing the libmxp_specialness.so file directly onto your roborio using pscp. You are then using putty to ssh into the roborio and set the file to executable so the ReliableI2C class can use it.
You will probably need to add the jna.jar to your build path. Here is a copy of what we used https://github.com/Cybersonics/2017SwerveTest/tree/master/build/jars
You will also need the Lidar and ReliableI2C classes to add to your code. The Lidar code here is similar to the code above but it uses the ReliableI2C class to find when there is a problem and correct for it. To initialize the whole group you will need to add
public static Pixy2 pixy;
public static Relay relay0, relay1;
public static Lidar lidar;
//public static DigitalOutput lidarReset;
public static Ultrasonic ultrasonic;
public static void init() {
ReliableI2C.init();
pixy = new Pixy2(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x54));
lidar = new Lidar(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x62));
to your robot initialization. You would still use lidar.getDistance() to get the distance in cm.
To run in Iterative robot you would still need to create the Lidar class and insert the code. You would put the items from the Robotmap section in the area where you initialize your robot. You would then call lidar.getDistance() where you need the distance value.
The noise on the line can be an issue. Last year our main Pixy camera and the Lidar ended up about as far away from the roborio as was possible making controlling noise difficult. It was literally placed diagonally across the robot from the roborio both horizontally and vertically. This caused our lines to be longer then they should have been. Still well within limits for I2C but longer then we would have preferred. They also had to go around several power wires, Talons, and were right over two motors for our right front drive. On our particular bot the worst noise offender seemed to be our 775pro powered shooter which happened to have a second pixy camera located near it, also on the I2C bus. Like I said earlier, changing over to shielded wire helped. You should note that we only ground one end of the shield wire, in our case the end closest to the roborio to prevent weird loops in the shield. We still did have occasional issues though where the I2C bus would lock up. What we found was that the I2C line would hang with the one line held high indefinitely. We believe that the noise from the motor(s) would occasionally trigger a spike on the I2C bus that made the bus think there was another I2C master on the line. Being that I2C is a multi-master multi-slave system the roborio master would then simply wait for the new master to complete it’s transmission which of course is never going to happen. We never did put a scope on the line to confirm this, but every time it occurred a digital logic probe showed the lines stuck in the same manner that seemed to indicate the transmission was waiting for completion. Now mind our theory on this could be wrong and if anyone else has better info or a better theory on the lock up problem we would be glad to hear it. In the end we did find that if we forced the line that was held high to a low state it and then released it the bus would restart. It should be noted that the I2C bus on the Roborio is a software controlled bus using two special DIO pins. On the MXP board they are DIO pins 24 and 25. What our one programming mentor did was to write a library file for the Roborio at the roborio level allowing us to selectively switch MXP pins 24 and 25 from I2C mode to DIO mode and back. By doing this we were able to track when an “event” occurred, switch modes to allow us to control the pins to reset the bus, and then switch the pins back into I2C mode to continue operations. Like I said this did not happen often after changing over to good wire, but we wanted to be sure it would never be a problem.
The following links are for the code we ended the season with. It is very similar to the code above but it adds in the ability to reset the bus as described. Just note that installing this takes a bit more effort then the code listed previously.
The fault correction for the I2C bus is here https://github.com/Cybersonics/MXPSpecial/tree/master/libmxp_specialness.
To install this copy the four files there and follow the directions in the readme file. Just remember to change the team number following roborio- to your team number. What you will be doing is installing the libmxp_specialness.so file directly onto your roborio using pscp. You are then using putty to ssh into the roborio and set the file to executable so the ReliableI2C class can use it.
You will probably need to add the jna.jar to your build path. Here is a copy of what we used https://github.com/Cybersonics/2017SwerveTest/tree/master/build/jars
You will also need the Lidar and ReliableI2C classes to add to your code. The Lidar code here is similar to the code above but it uses the ReliableI2C class to find when there is a problem and correct for it. To initialize the whole group you will need to add
public static Pixy2 pixy;
public static Relay relay0, relay1;
public static Lidar lidar;
//public static DigitalOutput lidarReset;
public static Ultrasonic ultrasonic;
public static void init() {
ReliableI2C.init();
pixy = new Pixy2(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x54));
lidar = new Lidar(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x62));
to your robot initialization. You would still use lidar.getDistance() to get the distance in cm.
To run in Iterative robot you would still need to create the Lidar class and insert the code. You would put the items from the Robotmap section in the area where you initialize your robot. You would then call lidar.getDistance() where you need the distance value.
The noise on the line can be an issue. Last year our main Pixy camera and the Lidar ended up about as far away from the roborio as was possible making controlling noise difficult. It was literally placed diagonally across the robot from the roborio both horizontally and vertically. This caused our lines to be longer then they should have been. Still well within limits for I2C but longer then we would have preferred. They also had to go around several power wires, Talons, and were right over two motors for our right front drive. On our particular bot the worst noise offender seemed to be our 775pro powered shooter which happened to have a second pixy camera located near it, also on the I2C bus. Like I said earlier, changing over to shielded wire helped. You should note that we only ground one end of the shield wire, in our case the end closest to the roborio to prevent weird loops in the shield. We still did have occasional issues though where the I2C bus would lock up. What we found was that the I2C line would hang with the one line held high indefinitely. We believe that the noise from the motor(s) would occasionally trigger a spike on the I2C bus that made the bus think there was another I2C master on the line. Being that I2C is a multi-master multi-slave system the roborio master would then simply wait for the new master to complete it’s transmission which of course is never going to happen. We never did put a scope on the line to confirm this, but every time it occurred a digital logic probe showed the lines stuck in the same manner that seemed to indicate the transmission was waiting for completion. Now mind our theory on this could be wrong and if anyone else has better info or a better theory on the lock up problem we would be glad to hear it. In the end we did find that if we forced the line that was held high to a low state it and then released it the bus would restart. It should be noted that the I2C bus on the Roborio is a software controlled bus using two special DIO pins. On the MXP board they are DIO pins 24 and 25. What our one programming mentor did was to write a library file for the Roborio at the roborio level allowing us to selectively switch MXP pins 24 and 25 from I2C mode to DIO mode and back. By doing this we were able to track when an “event” occurred, switch modes to allow us to control the pins to reset the bus, and then switch the pins back into I2C mode to continue operations. Like I said this did not happen often after changing over to good wire, but we wanted to be sure it would never be a problem.
I figured it out. It turns out the header pins that we put on the ends of the Lidar’s wires weren’t put on correctly. I now have full communication between the Lidar and an Arduino board. It’s accurately reading without any issues. Now all I have to do is hook it up to the roboRIO after the break.
Glad to hear you got it working with the Arduino.
To run in Iterative robot you would still need to create the Lidar class and insert the code. You would put the items from the Robotmap section in the area where you initialize your robot. You would then call lidar.getDistance() where you need the distance value.
The noise on the line can be an issue. Last year our main Pixy camera and the Lidar ended up about as far away from the roborio as was possible making controlling noise difficult. It was literally placed diagonally across the robot from the roborio both horizontally and vertically. This caused our lines to be longer then they should have been. Still well within limits for I2C but longer then we would have preferred. They also had to go around several power wires, Talons, and were right over two motors for our right front drive. On our particular bot the worst noise offender seemed to be our 775pro powered shooter which happened to have a second pixy camera located near it, also on the I2C bus. Like I said earlier, changing over to shielded wire helped. You should note that we only ground one end of the shield wire, in our case the end closest to the roborio to prevent weird loops in the shield. We still did have occasional issues though where the I2C bus would lock up. What we found was that the I2C line would hang with the one line held high indefinitely. We believe that the noise from the motor(s) would occasionally trigger a spike on the I2C bus that made the bus think there was another I2C master on the line. Being that I2C is a multi-master multi-slave system the roborio master would then simply wait for the new master to complete it’s transmission which of course is never going to happen. We never did put a scope on the line to confirm this, but every time it occurred a digital logic probe showed the lines stuck in the same manner that seemed to indicate the transmission was waiting for completion. Now mind our theory on this could be wrong and if anyone else has better info or a better theory on the lock up problem we would be glad to hear it. In the end we did find that if we forced the line that was held high to a low state it and then released it the bus would restart. It should be noted that the I2C bus on the Roborio is a software controlled bus using two special DIO pins. On the MXP board they are DIO pins 24 and 25. What our one programming mentor did was to write a library file for the Roborio at the roborio level allowing us to selectively switch MXP pins 24 and 25 from I2C mode to DIO mode and back. By doing this we were able to track when an “event” occurred, switch modes to allow us to control the pins to reset the bus, and then switch the pins back into I2C mode to continue operations. Like I said this did not happen often after changing over to good wire, but we wanted to be sure it would never be a problem.
The following links are for the code we ended the season with. It is very similar to the code above but it adds in the ability to reset the bus as described. Just note that installing this takes a bit more effort then the code listed previously.
I have put our last years code on github. The fault correction for the I2C bus is here https://github.com/Cybersonics/MXPSpecial
To install this copy the four files there and follow the directions in the readme file. Just remember to change the team number following roborio- to your team number. What you will be doing is installing the libmxp_specialness.so file directly onto your roborio using pscp. You are then using putty to ssh into the roborio and set the file to executable so the ReliableI2C class can use it.
You will probably need to add the jna jar to your build path. Here is a copy of what we used https://github.com/Cybersonics/2017SwerveTest/tree/master/build/jars
You will also need the Lidar and ReliableI2C classes to add to your code. Our code for last year is here: https://github.com/Cybersonics/2017SwerveTest . The Lidar code here is similar to the code above but it uses the ReliableI2C class to find when there is a problem and correct for it. To initialize the whole group you will need to add
public static Pixy2 pixy;
public static Relay relay0, relay1;
public static Lidar lidar;
//public static DigitalOutput lidarReset;
public static Ultrasonic ultrasonic;
public static void init() {
ReliableI2C.init();
pixy = new Pixy2(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x54));
lidar = new Lidar(ReliableI2C.openDevice(I2CPort.MXP, (byte) 0x62));
to your robot initialization. You would still use lidar.getDistance() to get the distance in cm.
We recently got the Garmin Lidar sensor. We wrote our own I2C driver for it. But it didn’t work. So I got the code from this thread and tried it. It’s still not working. After carefully read through the thread, I decided to power it differently. I used to connect the sensor to either the onboard I2C bus or the MXP I2C bus (SCLK and SDATA) and connect the power from either an AnalogInput port or a Digital I/O port. None worked. Since we also have a NavX IMU, I decided to plug it to the NavX I2C and jumpered it to provide 5V. It worked with the code provided by this thread. So I got adventurous and tried our driver code again. It still didn’t work. I know our driver initializes the sensor slightly differently. So I decided to start off with the code from this thread and work out the differences. Surprisingly, the code from this thread doesn’t work anymore. So I am lost on when could have gone wrong. Adding some debug code to the code from this thread, I discovered that after sending the command 0x03 (or 0x04) to the ACQ_COMMAND register, it was waiting for the LSB of the status register to go zero but it never did. If I ran enough times, very rarely, the status BUSY bit will occasionally come back zero and I will get one sample of valid distance. But then it will go on a never ending wait on the busy bit again. Anybody got any suggestions on what else I could try? BTW, I did not have a 680uF capacitor across the power lines because I don’t believe it’s necessary. Is that my mistake?
Sorry, I only actually got it working with an arduino board. I can try and figure out the LIDAR + too for you.