LIDAR

[FlyOldPlanes]

Hello,

We have a couple of the PulsedLight LIDAR units. First off they are great, but they were a pain for us to get to work. We've browsed a bunch of the threads here without much luck. Here is what we found to get it working.

The MXP pins don't talk well to the LIDAR. The onboard not at all, which is previously documented. We kept thinking we were making an I2C mistake, but we weren't. We eventually noticed that if the connectors were mashed, we would get good comm. Odd since it always worked with the Arduino. To make a long story short, what we ended up having to do was put a 10k pull up resistor between the clock wire and the 5v. BINGO. 100% comm all the time. Here is a java example of using the LIDAR. I used the bit-math from tech2077's LIDAR.java post, thanks.

Here is a simple sensor example, no variables to make it obvious what address goes where. Sorry if it doesn't cut and paste well. Its my first post.

package org.usfirst.frc.PUT_YOUR_TEAM_HERE.robot;

import edu.wpi.first.wpilibj.SensorBase;
import edu.wpi.first.wpilibj.I2C;
import edu.wpi.first.wpilibj.Timer;

/**
*
*/
public class LidarSubsystem extends SensorBase{

I2C m_i2c;

public LidarSubsystem() {
m_i2c = new I2C(I2C.Port.kMXP,0x62);
initLidar();
}

public void initLidar(){
// nothing to do
}

public int getDistance() {

byte[] buffer;
buffer = new byte[2];

m_i2c.write(0x00, 0x04);
Timer.delay(0.04);
m_i2c.read(0x8f, 2, buffer);


return (int)Integer.toUnsignedLong(buffer[0] << 8) + Byte.toUnsignedInt(buffer[1]);
}


public void initDefaultCommand() {
// Set the default command for a subsystem here.
//setDefaultCommand(new MySpecialCommand());
}


}

Here is a simple robot code to demonstrate:

package org.usfirst.frc.PUT_YOUR_TEAM_HERE.robot;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.Joystick;
import edu.wpi.first.wpilibj.RobotDrive;
import edu.wpi.first.wpilibj.Timer;
import edu.wpi.first.wpilibj.livewindow.LiveWindow;

/**
* The VM is configured to automatically run this class, and to call the
* functions corresponding to each mode, as described in the IterativeRobot
* documentation. If you change the name of this class or the package after
* creating this project, you must also update the manifest file in the resource
* directory.
*/
public class Robot extends IterativeRobot{

LidarSubsystem lidar1;

/**
* This function is run when the robot is first started up and should be
* used for any initialization code.
*/
public void robotInit() {

lidar1=new LidarSubsystem();

}

/**
* This function is run once each time the robot enters autonomous mode
*/
public void autonomousInit() {
}

/**
* This function is called periodically during autonomous
*/
public void autonomousPeriodic() {

int distance;

distance = lidar1.getDistance();
System.out.println(distance); // this prints to the console window.

}

/**
* This function is called once each time the robot enters tele-operated mode
*/
public void teleopInit(){
}

/**
* This function is called periodically during operator control
*/
public void teleopPeriodic() {

}

/**
* This function is called periodically during test mode
*/
public void testPeriodic() {
LiveWindow.run();
}

}

Hope it helps somebody. We sure could have used the info earlier.

Lennie
First time mentor.

[Fauge7]

Could you post more about the wiring of an I2c device and how you got that working

[FlyOldPlanes]

Wire up a 5v I2C device by connecting the SCL and SCA pins to the SCL and SDA pins on the MXP connector. Take power and ground from any 5v power and ground on the roborio.

To get I2C working, we worked our way up by first blinking an led with the digital IO, that was a good confidence builder that we could turn a pin on and off.

Next we hooked up an old kit of parts accel to work out the I2C communications. It worked with the built in Java class in WPILIB. Knowing that it indeed worked, we next wrote an accel class similar to the attached Lidar class. This helped us get confident that we could write our own code to talk over I2C. The accel actually requires more steps since you have to do I2C writes to turn the accel on and set the range. That worked fine also.

Next we tried the Lidar. It was very frustrating that it didn't work. Having more confidence in our I2C from our accel example, we worked more on the Lidar side. We tried several things. Checking connections, mashing wires, a logic level converter, and finally happened on the fact that we needed a pull up resistor, and only on the SCL wire. We actually crimped it right in to our wiring.

For the code steps to get I2C working, see the attached files from the first post. That method should work with any I2C device. Just use the addresses from the datasheet for your device. Use 7bit address, just like you are using arduino. For the Lidar in particular, if you store the variables as type byte, you will get an error doing the multi byte read to 0x8f. It does not fit in a byte, use an int or just write it in like the Lidar example.

I can't stress enough the value of working with the kop ADXL345 external accel first. It really helped build confidence that we were doing I2C right. We wasted a bunch of time fiddling with this and that in the code, while wondering if we were connecting to the right pins, while also working with an untested and poorly documented (for Roborio) sensor. We were better off getting good code with a tested sensor first, then moving to the Lidar.

Lennie

Always read the datasheet

[FlyOldPlanes]

The pull up resistor goes from 5v to the SCL pin.

[dednor]

THANK YOU!!!! You just saved me hours of headache. I was walking the same path you were.... I had a few hours this week, so I decided to experiment with Java/FRC+PulsedLight LIDAR. Things were going well, but I couldn't figure it out (didn't yet invest the time you did, but a couple of hours in with no luck). Thanks again for this post.

I had the same experience with Arduino. Maybe their clock line has a more effective pull-up resistor? Hmmm... curious now.

Regards,
-dednor