Lidarlite merge and bringup

[bansiesta]

This branch brings the WIP PRs #1949 and #2196 to a working state.
Also merged now is #2200.

The PR also contains: #2222

Feel free to review, comment and test, thanks.

Things tested:

• pwm_input start
• pwm_input test
• ll40ls start pwm
• ll40ls test pwm
• DISTANCE_SENSOR message in QGroundControl

nsh> pwm_input start
nsh> ll40ls start pwm
nsh> ll40ls test pwm
ll40ls: single read
ll40ls: measurement: 1.81 m
ll40ls: time:        0
ll40ls: periodic read 0
ll40ls: measurement: 1.842 m
ll40ls: time:        0
ll40ls: periodic read 1
ll40ls: measurement: 1.842 m
ll40ls: time:        0
ll40ls: periodic read 2
ll40ls: measurement: 1.818 m
ll40ls: time:        0
ll40ls: periodic read 3
ll40ls: measurement: 1.807 m
ll40ls: time:        0
ll40ls: periodic read 4
ll40ls: measurement: 1.836 m
ll40ls: time:        0
ll40ls: PASS
nsh> ll40ls info pwm
state @ 20014c40
ll40ls_pwm_read: 218 events, 0 overruns, 12104us elapsed, 55us avg, min 34us max 2471us 165.817us rms
ll40ls_pwm_read_errors: 1 events
ll40ls_pwm_buffer_overflows: 208 events
ll40ls_pwm_zero_resets: 1 events
ll40ls: poll interval:  50 ticks
ll40ls: distance: 1.839m

Also, the reset on Aux pin 6 seems to be working:

nsh> Idle Task: Lidar is down, reseting

[TSC21]

@LorenzMeier probably better check if QGC gets all the range sensors data plotted. Then probably we can merge. Still, we probably have to work first in a multi pub/sub implementation.

[bansiesta]

@LorenzMeier: I'll update the wiki instructions when it is merged. I would like if you could review the part here #2224 (diff)

[mhkabir]

@TSC21 Did you modify the flow driver to publish the sonar to a ranger topic? As-is, there isn't anything of that sort, so you won't get any data out.

[TSC21]

@mhkabir isn't this: https://github.com/PX4/Firmware/pull/2200/files#diff-d9c39530a9fff85e8b746162990ca263R420 supposed to be enough?

[mhkabir]

@TSC21 Oh no! We deprecated the serial interface quite some time back. Actively supported is only i2c.
Driver here : https://github.com/PX4/Firmware/tree/master/src/drivers/px4flow
Please make the changes and test :) Thanks!!

[TSC21]

Yes I was talking with @bansiesta at gitter now about this. He's already getting around that

[bansiesta]

The PX4Flow sonar distance is now published to distance_sensor as well, however, the multi pub/sub does not seem to work yet. It will need some changes.
@LorenzMeier pointers welcome :)

[TSC21]

The PX4Flow sonar distance is now published to distance_sensor as well, however, the multi pub/sub does not seem to work yet. It will need some changes.

Confirmed :D One idea for multi sub/pub: 571457a

[LorenzMeier]

You need to use orb_publish_multi()

[bansiesta]

I've added orb_advertise_multi in all distance sensors now, however, the modules using the data are all subscribing to the default (0).

I've tried the lidarlite together with a PX4Flow connected:

nsh> ls /dev
...
range_finder0
range_finder1
...

[TSC21]

@bansiesta so how can we choose what structure each module subscribe to?

[TSC21]

I was checking, we probably have to use orb_subscribe_multi() in every module, depending on the sensor instance.

Note: In this case, if we then use serial interface, do we have to create a mavlink stream for each sensor?

[bansiesta]

Note: In this case, if we then use serial interface, do we have to create a mavlink stream for each sensor?

I assume so. For now though, we can leave it as is and merge it, in my opinion. If later a module needs to subscribe to more than one, it can/should do so.

[TSC21]

Ekf_attitude_position estimator does need more than one range finder, as it's also defined in code. Also, how can sensors be distinguished in a telemetry link and be presented separatly in QGC for example?

[TSC21]

Anyhow, we also should consider the ID to get to each one. I say that we should reserve like an array of IDs for each type of sensor. For example, 0 to 10 for sonar sensors and 11 to 20 to lidar (assuming of course that someone would connect 20 range finders to the BUS xD). Not sure the max size of the I2C bus though, but the current serial link can allow to retrieve sensor data from sensors connected to companion computers.

[TSC21]

Note: topic names should correspond to id of the sensor, which should correspond to the instance id of 'range_finderN', meaning 'distance_sensorN', with N=distance_sensor.id=N from 'range_finderN'. That way we can have a much more organized topic presentation and will allow multi sub/pub. Also we must consider sensor data coming from the serial stream and organize it the same way as the ones connected to the I2C bus.

[LorenzMeier]

Nice! Merging.

[LorenzMeier]

@TSC21 If you want to identify a particular sensor, send the sensor ID as part of the message, not as part of the topic name. Then the subscriber can pick the one it prefers based on ID / specs.

[TSC21]

@LorenzMeier and how can that be done at QGC/sdlog2 level for example? Cause in mavros implementation I already can.

[TSC21]

Also, I don't think this is complete while the multi subscription is not implemented. It doesn't make sense to have multi advertising without having multisubscription, having estimators requiring more than one range source (which is the case of ekf_att_pos_estimator).

[bansiesta]

Note: documentation updated here: https://pixhawk.org/peripherals/rangefinder?#pwm_usage

[jgoppert]

@bansiesta

I have it wired and reading via test, but daemon process fails to start.