View Single Post
  #17   Spotlight this post!  
Unread 12-28-2017, 02:18 PM
GlassMaker's Avatar
GlassMaker GlassMaker is offline
Registered User
AKA: Carlos
FRC #0103 (Cybersonics)
Team Role: Mentor
Join Date: Mar 2017
Rookie Year: 2015
Location: Kintnersville, PA
Posts: 26
GlassMaker will become famous soon enough
Re: How do I use the LIDAR with a NavX-mxp?

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

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 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

You will also need the Lidar and ReliableI2C classes to add to your code. Our code for last year is here: . 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() {


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.
Reply With Quote