ADC system refactor

[SalimTerryLi]

Describe problem solved by this pull request
Refactor adc. Moving adc out of DriverFramework. Aim to get a more flexible adc system.

Describe your solution

1. make adc_report.msg contains more useful information
2. reduce hard-coded macros
3. let adc data receptor decide which adc device and channel it make use of by parameters or any other way.

This adc system works like mpu9250 with similar deviceID management. It supports multiple adc drivers and support multiple adc subscriber.
ADC driver publish adc_report, analog battery/airspeed driver wrapper subscribe the uorb topic and pick up information they need.
Old architecture-specific call in drv_adc.h should be deprecated.

Additional context
WIP, support needed.

[dagar]

This generally looks like the right direction. At some point I'd like to update all the ADC access to go through ORB rather than /dev/adc0.

In a configurable system with an ADS1115 on I2C how were you planning to specify which channels correspond to voltage, current, etc?

[SalimTerryLi]

This generally looks like the right direction. At some point I'd like to update all the ADC access to go through ORB rather than /dev/adc0.

In a configurable system with an ADS1115 on I2C how were you planning to specify which channels correspond to voltage, current, etc?

Drivers can provide adc samples with device ID and channel information which stay unchanged during power cycles. The most configurable solution would be two parameters on a function. For example, battery monitor checks params "INPUT_DEVICE_ID" & "ADC_CHANNEL", then it can filter uorb msgs which have device_id field matched. If there should not be this much flexibility, using start-up configuration is another choice.

[SalimTerryLi]

I have updated ADS1115 driver as a example and a wrapper for analogue differential sensor. They works as below:

pxh> uorb top
update: 1s, num topics: 51
TOPIC NAME                       INST #SUB #MSG #LOST #QSIZE
vehicle_local_position              0    6  124   206 1
position_setpoint_triplet           0    2   18     0 1
sensor_combined                     0    1  248     0 1
sensor_baro                         0    2   59     0 1
sensor_accel_status                 0    1    9     0 1
sensor_gyro                         0    1  986     0 1
sensor_gyro_status                  0    0    9     0 1
sensor_accel                        0    1  248     0 1
sensor_accel_integrated             0    2  248     0 1
sensor_gyro_integrated              0    2  248     0 1
vehicle_acceleration                0    2  248   197 1
vehicle_air_data                    0    2   59    54 1
vehicle_angular_velocity            0    3  986  1705 1
sensor_preflight                    0    0  248     0 1
ekf2_timestamps                     0    0  248     0 1
sensor_mag                          0    1   87    10 1
vehicle_attitude                    0    4  248   232 1
adc_report                          0    1   19     0 1
manual_control_setpoint             0    3    3     0 1
vehicle_imu                         0    0  248     0 1
vehicle_magnetometer                0    2   75     0 1
sensor_bias                         0    3  124     0 1
estimator_status                    0    3  124    25 1
estimator_innovations               0    1  124     0 1
estimator_innovation_variances      0    1  124     0 1
estimator_innovation_test_ratios    0    1  124     0 1
vehicle_odometry                    0    0  124     0 1
actuator_controls_0                 0    2  248     0 1
actuator_controls_2                 0    0  248     0 1
differential_pressure               0    2   19     0 1
pxh> listener differential_pressure

TOPIC: differential_pressure
 differential_pressure_s
	timestamp: 631024047  (0.008174 seconds ago)
	error_count: 0
	differential_pressure_raw_pa: nan
	differential_pressure_filtered_pa: nan
	temperature: -1000.0000
	device_id: 0 (Type: 0x00, UNKNOWN:0 (0x00)) 

I haven' t connected a real airspeed module on to ADS1115 because I did not bring it home but that is enough to show how this new design work. I would make a battery wrapper as well very soon. Any ideas?
BTW, I cannot find a proper way to poll the uorb update, this may lead to message lost.
@dagar

[SalimTerryLi]

battery_status is almost done. I marked out some code as TODO for that I'm not sure how it works.
The last function requires ADC could be RC RSSI. I'm not sure how to convert all existing adc drivers to use this new framework but it should be not too annoying.
ADC drivers should publish its raw sample count with valid bit width precision and voltage reference value. These specification can be determined at driver level to avoid complex overall macros.

[SalimTerryLi]

Now it supports generating battery monitor and RC RSSI reports from configurable adc reports. Remainder tasks including creating correct startup scripts which set the coresponding parameters for each boards.

[SalimTerryLi]

A critical problem exists if multiple adc drivers publishing. Some of topics may be overwrite and the subscriber would fall to catch. This is mostly a subscriber side problem and can be fixed if there is any polling logic.

[dagar]

A critical problem exists if multiple adc drivers publishing. Some of topics may be overwrite and the subscriber would fall to catch. This is mostly a subscriber side problem and can be fixed if there is any polling logic.

In what case are there multiple?

[dagar]

Related, I had create an analog airspeed "driver" in #13586.

[dagar]

Why 2.5?

[SalimTerryLi]

Sorry, this is incorrect.

[dagar]

Let me know when this is ready for an overall review. The battery_status changes need a careful review and test on existing systems.

If it makes sense you might consider carving this off into small little pull requests that are easier to review and test in isolation.
For example

• replacing /dev/adc0 with ORB_ID(adc_report)
• analog airspeed driver
• standalone ADS1115
• etc

[SalimTerryLi]

Let me know when this is ready for an overall review. The battery_status changes need a careful review and test on existing systems.

If it makes sense you might consider carving this off into small little pull requests that are easier to review and test in isolation.
For example

* replacing `/dev/adc0` with `ORB_ID(adc_report)`

* analog airspeed driver

* standalone ADS1115

* etc

Should I deprecate this PR and create those instead? battery_status would be affected at the very beginning when ioctls are replaced. Analog airspeed module and standalone ADS1115 driver almost have no impact at all.

To bring back battery_status, there should be proper drivers avaliable. I'm not sure whether drivers/adc meets the requirements.

[dagar]

To bring back battery_status, there should be proper drivers avaliable. I'm not sure whether drivers/adc meets the requirements.

I'm not sure what you mean.

[SalimTerryLi]

To bring back battery_status, there should be proper drivers avaliable. I'm not sure whether drivers/adc meets the requirements.

I'm not sure what you mean.

drivers/adc is fine. A unique device ID is required. Is it OK to add something like #define DRV_ADC_DEVTYPE_ONBOARD 0x70 into drv_sensor.h? then it can be the default value of dev_id parameter. The parameter for channel selection would be set in start-up script. This is not elegant enough but I have no other ideas now.

drivers/adc can dump all channels into uorb message, but I think it should be removed at all. Each board should has its own ADC driver.

[SalimTerryLi]

Deprecated.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.