Connecting LIDAR TF-Luna to the Roborio

Hi! We want to work with LIDAR TF-Luna.
Trying to figure out the best connection interface for our usage.
If I understand the datasheet correctly we can use the I2C or the RS-232 connection using a 5V from DIO(?).

Which is better? More reliable? Faster? Any better options?

We have some experience with another distance sensor connected to the I2C, sometimes, when the robot experience some burnout the sensor gets disconnected and only a full system reset helps, there is no way to reset the I2C interface manually! is it also true for the RS-232 connection?

Oooh that’s a good one.

Brownout is indeed going to be rough for both - it’s just a fundamentally hard problem if the sensor could (in theory) be put into any unknown state at any time due to electrical fluctuations. You may want to consider powering it off of a buck-boost supply (example) which can maintain output voltage over a very wide range of input voltages.

From there, eeh, it’s a tossup in my opinion. If RS232 works such that the sensor just starts spewing out the right data as soon as you turn it on (which, per this datasheet, is maybe what it does?), that might be a more robust option. Additionally, the 2020 RIO firmware has some I2C issues that (as far as I know) remain unfixed and have an unknown root cause.

Thanks for the info! is it true that I2C is slow compare to other intefaces?

It can be, it depends on what we’re comparing it to. But, I think the question needs to be a bit more refined.

The question I’d actually be asking is - Can the device support the data rate you need?

Just getting the data back from the sensor is the first number I would consider to answer this question.

For a quick example, assume that you want new data every 20ms (ie, 50 times per second), and the data is 32 bits long. You therefore need a datalink with at least a rate of 32 * 50 bits per second, or at 1.6 kbps link.

You should re-run this calculation with your numbers, and see whether I2C or RS232 can meet your requirements.

Some additional constraints you might have:

If you have to have your software “block” while the sensor transmits the data, you have a new timing constraint to consider. You may also be able to collect the data “asynchronously” in the background to help meet this constraint.

Additionally, the transmission time will (likely) be the biggest delay between when the sensor makes an observation, and when that observation is available for use in your controls code. How much this matters will depend on how you are using the data to control the robot.

I think 20ms will be enough, using the RS 232 connection, the 5V can come from a random DIO?

Is it compatible with the sensor’s TXD and RXD pins?

Please reference my initial response:

You said the RIO brownout behavior was causing issues, so I assume you need some other solution, hence my recommendation.

There are many answers which will “work” when brownouts are not present, but will fail at different times during brownout conditions. You’ll need to understand what failure mode you’re actually trying to prevent to evaluate whether any particular solution will solve it.

This information is present in the datasheet:

Since I do not see “5v tolerant” or “15v tolerant” in the datasheet, I would assume directly connecting to the RIO without a level-shifter in between will destroy the sensor.

1 Like

Well, we ended up trying to use the sensor while using the I2C connection, but the sensor doesn’t seem to respond at all.
We connected the sensor to a 5V pin while trying to use both the onboard connection and the MXP one, none of them resulted in any input from the sensor.
Before that, we tried wiring the sensor directly to a USB without knowing we need a TTL - USB
converter, maybe it killed him? We do see the sensor light when it’s connected to the I2C, so I don’t think the sensor is not working(?).

I will add a code sample later this day

Possibly. As a debug step, I’d grab an arduino with the arduino library (or any other known-functional 3.3v board) wire it up quickly, and read some data out of it. That way, you can eliminate one of the variables in your debugging effort when integrating with the roboRIO.

It will be our next step, hope to come back with good news.
Thanks for your help!

1 Like

@gerthworm has posted a lot of good advice on how to evaluate your application. If you are very concerned about brownouts, the suggestion he made about providing a guaranteed stable supply for the sensor is especially important. It would be good to test to verify that the solution you develop is sufficient for the duration of brownouts you are anticipating.

Based on my past experience in conducting EMC immunity testing where we blast our products with various forms of electromagnetic interference, it is difficult to state with any certainty whether the I2C or the RS232 interface will work better for your application. A lot depends on details of how the electronic hardware and software in the Roborio and the LIDAR were designed. The only way to know for sure is to test thoroughly under the conditions you are concerned about. One possible outcome is that neither interface gives satisfactory results.

If you are concerned about the integrity of the data from your sensor, it would probably be a good idea if the software your team writes includes some sort of continuous sanity checks on the data from the sensor so that your software is not using corrupted data for making decisions.