We’re trying to get the LIDAR Lite v3 working over I2C with Java. Unfortunately, we don’t know how to actually get it up and running over I2C, and how to code for it.
Do you have to add any vendordeps, and can someone give us some example code to get us up and running?
Thank you!
there aren’t really vendordeps for it, so you’ll have to develop your own interface. Luckily, there is already a lot of Arduino code out there for people that have figured out to talk to the LIDAR Lite, like Sparkfun’s Arduino Library. You’ll have to understand c++ and how I2C works in general, but there are good articles on that.
We had far more luck using the DIO ports to read the PWM output of the sensor. It worked extremely well. There is labview code out there for it that should be pretty easy to port over if native code if your language doesn’t exist already. The I2C functionality on the Rio has been notoriously difficult to use for many teams.
Difficult in LabVIEW or with the roboRIO in general? Are there abstractions missing, or is it unreliable?
abstraction? what’s that? /s
I would be interested in this if you would be willing to share. I was unaware PWM was an option.
Last year, my team used this GitHub page as a reference to get our LIDAR Lite set up. We ended up going the PWM route (as both the page and the posters before me state, it’s more reliable and we had I2C routed to something else already), and it worked very nicely for us.
Huh. Missed the /s at the end. But I’m leaving the explanation just because you typed that sentence. 
An abstraction is a programming term that refers to a structure that hides unneeded complexity from the user. That can be a subVI, a subroutine, or any one of a number of things in object oriented programming.
I’m not aware of any missing abstractions - just difficulties with the I2C and constant speculation if it is the MXP, the dedicated port, or the peripherials as well. You can find a number of threads here about it, and we’ve experienced a number of inconsistent behaviors with gyros, pixy cams, and the lidar lite that has led us to avoid it if we can.
There are differences in I2C communications between the different versions of the Lidar lite. There is a post here with labview code they claim works with the I2C (this is V1 I believe):
Here is the code from CTRE to run the Lidar Lite with a canifier in labview:
Here is text code that you might be more used to, all credit to Joe Jackson and the Girls of Steel (PWM):
Another option (PWM):
Here is the code we played with for I2C and were not successful with:
https://forums.ni.com/t5/image/serverpage/image-id/221058i73F80548BE93CE0B/image-size/large?v=v2&px=999
Unfortunately, I do not have access to anything google-related at work so I cannot post the PWM Labview code I have stored there.
Excellent post, although the /s indicated I was being sarcastic. I have a tendency to not do a very good job at abstracting functions because it’s just now how my brain works and drives people developing with me a little insane. I’ve started to get a lot better at it though now that I’m writing code in languages that make it more enjoyable.
Were the RIO freeze-up issues from a year ago ever driven to root cause? It didn’t sound like I2C was expected to be the actual root cause, just an exacerbating factor?
Yea, the lockups were traced to I2C. Idk how many specifics I can give. You can work around it by using the MXP I2C interface.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.