px4 / driverframework Goto Github PK

View Code? Open in Web Editor NEW

80.0 80.0 132.0 960 KB

Operating system and flight stack agnostic driver framework for POSIX (Linux, NuttX, Mac OS, QNX, VxWorks).

CMake 13.49% Makefile 0.18% C++ 84.77% C 1.57%

driverframework's People

Contributors

Stargazers

Watchers

Forkers

hoocolinbooks atlflight sulvsi fyiot mors25 beechuilajung shaosanye aerobota ndepal 9dsmart 3drobotics bkueng pola14225 eattomatoes lsr123 tigerwood matthewzhenggong mayanez ultrasystem eyeam3 izhanghui lucasdemarchi ericye16 willendzw branux stu85010 carlowood leeoxe forethewind lhc610github manusaerotech imquentin romanbapst ravenklee mkapuscik zhuchunwu aerotenna zangel lmhtz mhkabir christophtobler zt1217396582 crossa davidaroyer dennisss faical-yannick-congo olegccc scenkov krbeverx ursa-drone ad-aleksandrov mujanfun namezis ripple3 vgatemjc ericyao2013 bigdata-page eugenelo andy-zr alexshilucky alexxnica landeru priestd09 allrsb aogrcs bo-rc serkanyilmaz cmzww bob-f skystalkerrc lulzzz auradu2011 bruce1634 qingyinana spiritcity uav-pilot masz106 yaseralyaser123 parallaxisjones jedichen121 bellanana curioustauseef uav360 bmqh642970637 trident007 bartslinger clpopescu-1999-02 jasonisnotmyrealname sfalexrog albert-zjm yukun2016 zsigmondszilveszter lovelyduoduo xu-y-ang githubyang49 redcosmos jasperfun silentjet spurmoon carawayyy

driverframework's Issues

Link to termios libs

How can we link to the termios libs?
Help would be appreciated, thanks.

[08500/03]  05:46.070  HAP:45:undefined PLT symbol fcntl (135) /libpx4muorb_skel.so  0303  symbol.c
[08500/03]  05:46.070  HAP:45:undefined PLT symbol tcgetattr (1316) /libpx4muorb_skel.so  0303  symbol.c
[08500/03]  05:46.070  HAP:45:undefined PLT symbol cfsetispeed (891) /libpx4muorb_skel.so  0303  symbol.c
[08500/03]  05:46.070  HAP:45:undefined PLT symbol cfsetospeed (1300) /libpx4muorb_skel.so  0303  symbol.c
[08500/03]  05:46.070  HAP:45:undefined PLT symbol tcsetattr (257) /libpx4muorb_skel.so  0303  symbol.c

Unit test for SyncObj was disabled, masked bug in waitOnSignal

It seems the Apple implementation works, but the Linux implementation does a pthread_cond_timedwait on a monotonic clock time vs a realtime clock time and therefore returns immediately as a timeout.

This was masked because the SyncObjTest was ifdefed out.

Unit tests fail on Mac

The unit tests fail on Mac and are therefore currently disabled (851c711).

18446744073709551615 ======= BEGIN TESTS FOR Framework Test
30 pthread info: policy=SCHED_FIFO priority=10
43 ======= BEGIN TESTS FOR List Tests
71 ------- BEGIN FEATURE TEST FOR Unmanaged list tests
75 TEST Verify empty() true on list creation: PASSED
91 TEST Verify pushBack(): PASSED
95 TEST Verify next() pushFront() and erase(): PASSED
98 TEST Verify clear(): PASSED
100 ------- BEGIN FEATURE TEST FOR Managed list tests
103 TEST Verify empty() true on list creation: PASSED
106 TEST Verify pushBack(): PASSED
108 TEST Verify next() pushFront() and erase(): PASSED
112 TEST Verify clear(): PASSED
113 ------- BEGIN FEATURE TEST FOR UInt list tests
115 TEST Verify empty() true on list creation: PASSED
118 TEST Verify pushBack(): PASSED
121 TEST Verify next() pushFront() and erase(): PASSED
123 TEST Verify clear(): PASSED
125 ======= END OF TESTS FOR List Tests. 12 of 12 tests passed
127 TEST List tests: PASSED
129 ======= BEGIN TESTS FOR Sync Obj Test
131 TEST Simple lock/unlock: PASSED
6417 waitSignal() timeout of 5000us was 6283us
6432 TEST waitSignal() timeout: FAILED
6435 ======= END OF TESTS FOR Sync Obj Test. 1 of 2 tests passed
6437 TEST Sync tests: FAILED
6439 ======= BEGIN TESTS FOR Time Test
7729 Usleep of 1000us reported delta of 1287us
1009827 Sleep of 1s reported delta of 1002097us
1009854 TEST Verify offsetTime(): FAILED
3013958 TEST Verify verifyAbsoluteTime(): PASSED
5019194 TEST Verify verifyAbsoluteTimeInFuture(): PASSED
5019228 ======= END OF TESTS FOR Time Test. 2 of 3 tests passed
5019236 TEST Time tests: FAILED
5019240 ======= BEGIN TESTS FOR DevMgr Test
5019320 Added driver 0x7fff54e5a548 /dev/test0
5020737 TEST Verify start(): PASSED
5020782 TEST Verify registerDriver(): PASSED
5021014 TEST Verify updateNotify(): PASSED
5021046 ======= END OF TESTS FOR DevMgr Test. 3 of 3 tests passed
5021055 TEST DevMgr tests: PASSED
5021058 ======= BEGIN TESTS FOR WorkMgr Test
5021391 Delay: 0usec Expected: 5021098 Actual: 5021120 Delta: 22usec
5021424 Delay: 0usec Expected: 5021098 Actual: 5021121 Delta: 23usec
5021435 Delay: 0usec Expected: 5021098 Actual: 5021123 Delta: 25usec
5021439 Verified 0usec timeout
5021749 Delay: 1usec Expected: 5021445 Actual: 5021487 Delta: 42usec
5021759 Delay: 2usec Expected: 5021446 Actual: 5021489 Delta: 43usec
5021762 Delay: 3usec Expected: 5021447 Actual: 5021491 Delta: 44usec
5021764 Verified 1usec timeout
5022089 Delay: 10usec Expected: 5021777 Actual: 5021800 Delta: 23usec
5022101 Delay: 20usec Expected: 5021787 Actual: 5021801 Delta: 14usec
5022106 Delay: 30usec Expected: 5021797 Actual: 5021803 Delta: 6usec
5022110 Verified 10usec timeout
5053135 Failed to get 3 callbacks (2)
5053169 TEST Verify Schedule: FAILED
5053178 ======= END OF TESTS FOR WorkMgr Test. 0 of 1 tests passed
5053182 TEST WorkMgr tests: FAILED
5053185 ======= END OF TESTS FOR Framework Test. 2 of 5 tests passed
5053190 shutdown

M_PI_F not available

It would be nice if dspal_math.h also contained the float constants and not just the doubles.

could you add rc in. rc out. adc sim. i want use pxio board

Using pthread_cond_timedwait() can lead to hang

PX4/PX4-Autopilot#3726

Instructions how to use tests

There seem to be unit tests for the DriverFramework, however, I don't see instructions how to use them.

MPU9250 stop leads to adsp reset

The adsp appears to reset when the driver is stopped and cleaned up.

Steps to reproduce:

cd /home/linaro
./df_imu_test_app

This can be reproduced with 5745908

Accelerometer readings are offset on some MPU9250 devices

On some MPU9250 devices, the accelerometer readings are offset. For example, this is the output of df_imu_test on a board that is sitting flat and stationary:

[08500/00]  01:18.777  HAP:12349:18446744073709551552 WARNING: setRealtimeSched failed (not run as root?)   0357  DriverFramework.cpp
[08500/00]  01:18.878  HAP:12350:100810 Reset MPU9250   0170  MPU9250.cpp
[08500/00]  01:18.885  HAP:12350:107897 gyro self-test: 0xbd, 0xcb, 0xe2   0061  MPU9250.cpp
[08500/00]  01:18.885  HAP:12350:108120 accel self-test: 0x6a, 0x64, 0x79   0070  MPU9250.cpp
[08500/00]  01:18.888  HAP:12350:110672 accel self-test readings: 0xdb94, 0x16a, 0xf93d   0099  MPU9250.cpp
[08500/00]  01:18.890  HAP:12350:113111 accel non-self-test readings: 0xdd06, 0x438, 0xfc8c   0115  MPU9250.cpp
[08500/00]  01:18.890  HAP:12350:113206 accel st and nonst diff readings: 0xfe8e, 0xfd32, 0xfcb1   0120  MPU9250.cpp
[08500/00]  01:18.890  HAP:12350:113300 accel st and nonst diff readings: 0x172, 0x2ce, 0x34f   0124  MPU9250.cpp
[08500/00]  01:18.953  HAP:12349:176300 IMU temperature initialized to: 47.542938   0587  MPU9250.cpp
[08500/00]  01:18.953  HAP:12350:176458 count: 1   0095  test.cpp
[08500/00]  01:18.955  HAP:12350:176517 IMU: accel: [-45.09, 1.06, -9.36] m/s^2   0143  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:176709      gyro:  [-0.05, 0.00, 0.00] rad/s   0147  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:176872      mag:  [0.000000, 0.000000, -0.000000] ga   0153  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:176954      temp:  47.54 C   0157  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:177152 count: 10   0095  test.cpp
[08500/00]  01:18.955  HAP:12350:177212 IMU: accel: [-45.11, 1.06, -9.19] m/s^2   0143  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:177386      gyro:  [-0.05, 0.00, -0.00] rad/s   0147  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:177530      mag:  [0.460793, -0.144281, 0.382002] ga   0153  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:177693      temp:  47.45 C   0157  ImuSensor.hpp
[08500/00]  01:18.955  HAP:12350:177812 Closing IMU sensor   0119  test.cpp
[08500/00]  01:18.965  HAP:12350:188241 Test PASSED   0140  test.cpp

I don't think this is a hardware issue because when I move it, the numbers change but they are offset. I tried setting the offset parameter in the hardware but it seems to reset every boot. This wasn't happening before so is it possible a bad calibration or something persistently changes the offset?
I also tried looking into the self-test features on the IMU but invensense doesn't seem to be willing to release those docs :(

Support for RPi/Navio

Let's keep track about the unit tests on the respective platforms:

	RPi1	RPi2	RPi2
Navio+
Navio2		MPU9250 pass

Sometimes MPU9250 doesn't initialize

Sometimes it appears that the MPU9250 doesn't initialize correctly:

   2643172: HAP:61:  arg0 = 'df_mpu9250_wrapper' (main.cpp:85)
   2643172: HAP:61:  arg1 = 'start' (main.cpp:85)
   2643172: HAP:61:1367420 Added driver f0914e20 /dev/imu0 (DevMgr.cpp:145)
   2643182: HAP:60:px4_getpid() called from unknown thread context! (px4_qurt_tasks.cpp:343)
   2643182: HAP:60:px4_getpid() called from unknown thread context! (px4_qurt_tasks.cpp:343)
   2643254: HAP:61:1469621 Reset MPU9250 (MPU9250.cpp:89)
   2643332: HAP:48:[posix-uORB::Manager::process_add_subscription(339)] entering Manager_process_add_subscription: name:  (uORBManager.cpp:339)
   2643332: HAP:48:[posix-uORB::Manager::process_add_subscription(351)]DeviceNode(sensor_combined) not created yet (uORBManager.cpp:351)
   2644136: HAP:61:2571514 I2C transfer timed out (MPU9250_mag.cpp:381)
   2644136: HAP:61:2571559 error reading mag whoami reg: -1 (MPU9250_mag.cpp:265)
   2644136: HAP:61:2571587 MPU9250 mag not detected. (MPU9250_mag.cpp:81)
   2644136: HAP:61:2571612 mag initialization failed 1 tries (MPU9250_mag.cpp:191)
   2645024: HAP:61:3682052 I2C transfer timed out (MPU9250_mag.cpp:381)
   2645024: HAP:61:3682095 error reading mag whoami reg: -1 (MPU9250_mag.cpp:265)
   2645024: HAP:61:3682123 MPU9250 mag not detected. (MPU9250_mag.cpp:81)
   2645024: HAP:61:3682148 mag initialization failed 2 tries (MPU9250_mag.cpp:191)
   2645912: HAP:61:4791611 I2C transfer timed out (MPU9250_mag.cpp:381)
   2645912: HAP:61:4791652 error reading mag whoami reg: -1 (MPU9250_mag.cpp:265)
   2645912: HAP:61:4791680 MPU9250 mag not detected. (MPU9250_mag.cpp:81)
   2645912: HAP:61:4791705 mag initialization failed 3 tries (MPU9250_mag.cpp:191)
   2646800: HAP:61:5901914 I2C transfer timed out (MPU9250_mag.cpp:381)
   2646800: HAP:61:5901956 error reading mag whoami reg: -1 (MPU9250_mag.cpp:265)
   2646800: HAP:61:5901985 MPU9250 mag not detected. (MPU9250_mag.cpp:81)
   2646800: HAP:61:5902010 mag initialization failed 4 tries (MPU9250_mag.cpp:191)
   2647688: HAP:61:7012191 I2C transfer timed out (MPU9250_mag.cpp:381)
   2647688: HAP:61:7012233 error reading mag whoami reg: -1 (MPU9250_mag.cpp:265)
   2647688: HAP:61:7012262 MPU9250 mag not detected. (MPU9250_mag.cpp:81)
   2647688: HAP:61:7012289 mag initialization failed 5 tries (MPU9250_mag.cpp:191)
   2647696: HAP:61:7022334 failed to initialize mag! (MPU9250_mag.cpp:202)
   2647696: HAP:61:7022364 Magnetometer initialization failed (MPU9250.cpp:176)
   2647696: HAP:61:MPU9250 device id is: 4288784 (df_mpu9250_wrapper.cpp:291)
   2647697: HAP:60:7023769 FIFO overflow (MPU9250.cpp:359)

Also, trying to start the MPU9250 without mag won't work at that point:

   2783748: HAP:52:32776650 Added driver f0945a50 /dev/imu1 (DevMgr.cpp:145)
   2783828: HAP:52:32876989 Reset MPU9250 (MPU9250.cpp:89)
   2783829: HAP:52:32878215 initializing mpu9250 driver without mag support (MPU9250.cpp:110)
   2783829: HAP:60:32878633 IMU temperature initialized to: 34.997231 (MPU9250.cpp:466)
   2783833: HAP:60:32883110 FIFO overflow (MPU9250.cpp:359)
   2783833: HAP:60:32883357 FIFO overflow (MPU9250.cpp:359)
   2783834: HAP:52:MPU9250 device id is: 4288784 (df_mpu9250_wrapper.cpp:291)
   2784168: HAP:69673:gyro has timed out (sensors.cpp:2200)
   2784168: HAP:69673:failing over to second gyro (sensors.cpp:2214)

FYI: @jywilson thoughts?

SD card and nsh

Document the magic nsh / mavlink switching by using an SD card or not.

This was raised by @Michvw.

The DF timer includes drift

@mcharleb @jywilson If you ask the DF for a callback at a 4000 us interval you're getting 4000 us + scheduling overhead, not 4000 us on average, which is a problem for us. I will look with @bkueng into this, but if you have availability it would be great if you could propose a fix.

IMU delta time calculation problem

The IMU drives are applying a first order low pass to the number of packets available in the FIFO buffer, see https://github.com/PX4/DriverFramework/blob/master/drivers/mpu6050/MPU6050.cpp#L445
The filtered value is used to calculate the delta time for each sensor sample.

This does not make sense and requires clarification of the original intent.

how use gpio as spi select

Hexagon SDK install on console never completes

When trying to install in Vagrant, the SDK install of this component gets stuck: qualcomm_hexagon_sdk_2_0_eval.bin

Earlier versions did work.

IIO support on Linux

Is anyone working on IIO support for Linux?

mini-dm creates a huge load when disconnected

Whenever the mini-dm somehow gets disconnected (e.g. through because the Snapdragon is restarted, or disconnected) but is still running, it seems to be busy looping and filling one CPU. It would be nice if it was slowed down just a bit while trying to reconnect.

This happens on Ubuntu and the Snapdragon Flight connected over USB2.0.

i2c write fail on start

2eb3d9b fails on PX4 startup:

1926824: HAP:61:In dspal_entry (main.cpp:214)
   1927100: HAP:61:attempting to open the ADSP command file: /dev/fs/px4.config (main.cpp:178)
   1927101: HAP:61:reading commands from /dev/fs/px4.config (main.cpp:185)
   1927156: HAP:61:Sleeping for 1, 1000000 (apps.h:118)
   1928102: HAP:61:1598159 Reset MPU9250 (MPU9250.cpp:89)
   1928154: HAP:60:1662432 IMU temperature initialized to: 55.210526 (MPU9250.cpp:496)
   1928157: HAP:61:1666599 additional sensor configuration succeeded (BMP280.cpp:187)
   1928158: HAP:61:start (df_trone_wrapper.cpp:203)
   1928160: HAP:61:I2C_Write failed: 285212872 num_bytes_written 0 (i2c.c:414)
   1928160: HAP:61:1669634 Error: i2c write failed. Reported -1 bytes written (I2CDevObj.cpp:215)
   1928160: HAP:61:I2C_Write failed: 285212872 num_bytes_written 0 (i2c.c:414)
   1928160: HAP:61:1669844 Error: i2c write failed. Reported -1 bytes written (I2CDevObj.cpp:215)
   1928160: HAP:61:I2C_Write failed: 285212872 num_bytes_written 0 (i2c.c:414)
   1928160: HAP:61:1670059 Error: i2c write failed. Reported -1 bytes written (I2CDevObj.cpp:215)
   1928160: HAP:61:I2C_Write failed: 285212872 num_bytes_written 0 (i2c.c:414)
   1928160: HAP:61:1670272 Error: i2c write failed. Reported -1 bytes written (I2CDevObj.cpp:215)
...

Fix 2nd pressure sensor driver

@eyeam3 This here is incorrect:
https://github.com/PX4/DriverFramework/blob/master/drivers/ms5607/MS5607.cpp#L354

It will block the execution of other sensor drivers because they run together in a work queue on the same thread.

It will need the same fix as this one here:
29b18fb

@julianoes FYI

I2C Driver: Confusion about operation on code inspection

@mcharleb I don't see from looking at the code how the BMP280 would return valid data - have you tested the version in master on hardware?

The reason I ask is the following sequence:

Registers are being read here:
https://github.com/PX4/DriverFramework/blob/master/drivers/pressure/bmp280/BMP280.cpp#L172

The I2C dev handle only becomes active here:
https://github.com/PX4/DriverFramework/blob/master/drivers/i2c/I2CDevObj.cpp#L47
which is called after the register reads
here:
https://github.com/PX4/DriverFramework/blob/master/drivers/pressure/bmp280/BMP280.cpp#L183

How are the read regs working if the FD does not exist yet?

MPU9250::start() calls DevOpen( ) which uses m_dev_instance_path

Why we need to use m_dev_instance_path in the open() function? i have to change it to m_dev_path to make RPi2 find the sensor.

Conflicting pid_t definitions

There are two conflicting definitions of pid_t around:

Firmware/src/lib/DriverFramework/dspal/include/termios.h:41:18: fatal error: typedef redefinition with different
      types ('__pid_t' (aka 'int') vs 'unsigned long')
typedef __pid_t         pid_t;
                        ^
Firmware/src/lib/DriverFramework/dspal/include/dspal_types.h:52:29: note: previous definition is here
typedef unsigned long int   pid_t;

Latest Emlid RPi2 image breaks DF

Just updated to the latest Emlid Raspbian image from here : https://docs.emlid.com/navio2/Navio-APM/configuring-raspberry-pi/

782161 overflow
782199 SPI speed set to 1MHz.
783143 SPI speed set to 1MHz.
783239 SPI speed set to 1MHz.
783332 SPI speed set to 8MHz instead of 10MHz.
783389 ERROR: SPI transfer bytes request over limit

Console is spammed with these messages on running the MPU9250 test app. @bo-rc could you have a look please.

Should lock in WorkItems be removed?

In WorkItems.cpp use inst.m_lock to make m_work_list and m_work_items thread-safe.
But m_work_list and m_work_items themself are already thread-safe list.
Is nessaccery to lock twice to make m_work_list and m_work_items thread-safe ?

Remove confusing errors/warnings

@mcharleb, @jywilson:

When using the DriverFramework or PX4 Firmware on the Snapdragon Flight, there are various confusing warnings/errors.

I would assume that they need fixing or removal. Otherwise, once more users start using the Snapdragon Flight, there will be plenty of confusion and support burden for us.

I'm referring to output like this:

/eagle-build/buildtree/oe-core/build/tmp-eglibc/work/cortexa8hf-vfp-neon-linux-gnueabi/adsprpc/1.0-r0/adsprpc-1.0/src/fastrpc_apps_user.c:136:failed to create tls key/eagle-build/buildtree/oe-core/build/tmp-eglibc/work/cortexa8hf-vfp-neon-linux-gnueabi/adsprpc/1.0-r0/adsprpc-1.0/src/listener_android.c:112:listener using ion heap: -1
/eagle-build/buildtree/oe-core/build/tmp-eglibc/work/cortexa8hf-vfp-neon-linux-gnueabi/adsprpc/1.0-r0/adsprpc-1.0/src/apps_std_imp.c:35:apps_std fopen failed: /usr/share/data/adsp//dev/mag0 No such file or directory
/eagle-build/buildtree/oe-core/build/tmp-eglibc/work/cortexa8hf-vfp-neon-linux-gnueabi/adsprpc/1.0-r0/adsprpc-1.0/inc/mod_table_imp.h:346::error: 2: 0 == (nErr = invoke_func_ptr(sc, pra))

coverity defects

DriverFramework defects from Coverity.

You can access them https://scan.coverity.com/projects/px4-firmware/view_defects
Ping me if you need access.

FIFO buffer corruption

Every now and then (about every 20th try) I get the FIFO buffer corruption on startup of the MPU9250 driver. A FIFO buffer reset of the sensor doesn't seem to fix the problem. Maybe a general sensor reset would help.

Trouble with mpu9250 on intel Edison

MPU9250.
Guys, help please!
I take data several times but after that the driver is hung.
And the driver is working random time before to hang.

Unit tests fail on master

make run fails on master:

0 ======= BEGIN TESTS FOR Framework Test
21 ======= BEGIN TESTS FOR List Tests
22 ------- BEGIN FEATURE TEST FOR Unmanaged list tests
23 TEST Verify empty() true on list creation: PASSED
24 TEST Verify pushBack(): PASSED
26 TEST Verify next() pushFront() and erase(): PASSED
27 TEST Verify clear(): PASSED
27 ------- BEGIN FEATURE TEST FOR Managed list tests
28 TEST Verify empty() true on list creation: PASSED
30 TEST Verify pushBack(): PASSED
31 TEST Verify next() pushFront() and erase(): PASSED
32 TEST Verify clear(): PASSED
32 ------- BEGIN FEATURE TEST FOR UInt list tests
32 TEST Verify empty() true on list creation: PASSED
33 TEST Verify pushBack(): PASSED
34 TEST Verify next() pushFront() and erase(): PASSED
34 TEST Verify clear(): PASSED
35 ======= END OF TESTS FOR List Tests. 12 of 12 tests passed
35 TEST List tests: PASSED
36 ======= BEGIN TESTS FOR Sync Obj Test
36 TEST Simple lock/unlock: PASSED
36 ======= END OF TESTS FOR Sync Obj Test. 1 of 1 tests passed
37 TEST Sync tests: PASSED
37 ======= BEGIN TESTS FOR Time Test
1001226 TEST Verify offsetTime(): PASSED
1001229 ======= END OF TESTS FOR Time Test. 1 of 1 tests passed
1001230 TEST Time tests: PASSED
1001230 ======= BEGIN TESTS FOR DevMgr Test
1001241 Added driver 0x7ffd174b5060 /dev/test0
1002373 TEST Verify start(): PASSED
1002382 TEST Verify registerDriver(): PASSED
1051436 TEST Verify updateNotify(): PASSED
1051444 ======= END OF TESTS FOR DevMgr Test. 3 of 3 tests passed
1051445 TEST DevMgr tests: PASSED
1051446 ======= BEGIN TESTS FOR WorkMgr Test
1051478 Verified 0usec timeout
1051487 Verified 1usec timeout
1051554 Verified 10usec timeout
1081640 Failed 10010 usec timeout * 3 (30081 > 30080)
1081641 TEST Verify Schedule: FAILED
1081641 ======= END OF TESTS FOR WorkMgr Test. 0 of 1 tests passed
1081642 TEST WorkMgr tests: FAILED
1081642 ======= END OF TESTS FOR Framework Test. 4 of 5 tests passed
1081643 shutdown

This even fails on CI Travis, but it does not report it as an error.
Looks like the tests use a very tight timing bound. By increasing the bound from 50 to 100us, the tests succeed on my machine.

Filter/integrate MPU9250 accel/gyro values

For the inav position estimator, we're only using 1 out of 32 samples for the gyro and 1 out of 16 samples for the accel because the FIFO buffer is read at 8 respectively 4 kHz but the data is only published at 250 Hz.

Instead of using only part of the available data, it would make sense to use the integrated values for the inav estimator (and logging) as well.

This problem does not apply to ekf2 because it uses the integral over 32 samples and not the instantaneous values.

Compile error: sys/ttydefaults.h

dspal/include/termios.h:99:10: fatal error: 'sys/ttycom.h' file not found
and
dspal/include/termios.h:100:10: fatal error: 'sys/ttydefaults.h' file not found

This happens when trying to compile the PX4 GPS driver.
Where would this file be? What is it for?

pthread_setschedparam on QURT not behaving

The call to dspal pthread_setschedparam() seems to fail on QURT:
https://github.com/PX4/DriverFramework/blob/master/framework/src/DriverFramework.cpp#L317

The return value is 48, and errno is 0.

Is this call supported? What does the return value mean?

Work queue change breaks SITL

@mcharleb I had to make the changes in 67cbaea to resurrect SITL. I made them in a way so they do not affect QuRT. Can you help us to understand if you think your recent change in e62faac was bad or if the barosim driver has a bug which was exposed by the change?

Submodule handling: Currently disabled

I have disabled the submodule handling on master currently because its non-transparent for developers. We might need to re-introduce something smarter as done in PX4 upstream.

DPLF settings for all drivers need review

@mcharleb @julianoes on average the DPLF setting should be set around 30-50 Hz on all platforms. We need to make sure that's the case.

sample_interval_usec is not essential for pca9685

Now I‘m tring to port driver of PCA9685 i2c module into DriverFramework.
I wrote a Class named PCA9685 extends I2CDevObj and I found the last parameter of I2CDevObj constructor named sample_interval_usec. This parameter is important for sensor drivers but is not necessary for pwm output.

I had read navio_sysfs_pwm_out.cpp and I found this driver run the main task without interval and output pwm signal in a while loop.

So the question is :
Is the sample_interval_usec essential parameter for the construnctor of I2CDevObj？
Pwm output processing should be written in a loop and this loop should always run until the driver stopped, so how do I do？

@julianoes

External mag HMC5883 needs to be started after GPS

The serial open call of the GPS currently leads to a crash if the HMC5883 driver is already running.
This needs investigation.

Sonar inoperative on Bebop 2

@eyeam3 Using current PX4 master, my Bebop 2 sonar does not return any measurements, staying stuck at -1.0m. I get very rare spikes with the seemingly correct distance sometimes. I checked using QGC and listener distance_sensor.

Let me know what you need to debug this, or let me know how I can help.

Remove printf in i2c.c

@mcharleb, @jywilson:

There seems to be an unnecessary leftover printf in i2c.c. It seems to appear on each I2CDevObj::_writeReg()

[08500/02]  59:18.731  HAP:69676:slave 0x1E bytes 2  0410  i2c.c
[08500/02]  59:18.740  HAP:69675:slave 0x1E bytes 2  0410  i2c.c

If I'm correct, could you please get rid of it?

Rework DF so we don't hardcode the sensor interface at compile time

I was wondering if there is interest in refactoring sensors so they take the adapter type (SPI/I2C/whatever) and path to the actual adapter at start time.

Example:
https://github.com/PX4/DriverFramework/blob/master/framework/include/BaroSensor.hpp#L43
Could actually have a DevObj *m_adapter, instantiated in ctor depending on parameters.

This could all go to relevant configs:
https://github.com/PX4/DriverFramework/blob/master/framework/include/ImuSensor.hpp#L45-L70

poll and pollfd not available?

Is it possible that we currently can't access poll and pollfd on QURT? This is needed in the GPS driver which wants to poll on the file descriptor of the UART.

See http://pubs.opengroup.org/onlinepubs/009695399/basedefs/poll.h.html

Linux and WorkQueues

Hello,

After surfing through the code I noticed that every DevObj's execute function is ran by the HRTWorkQueue.
Since all sensors inherit DevObj, and they interact with low speed busses like I2C, SPI, and all of these syscalls sleep, the latency and jitter will be high and unpredictable.
In my opinion, on Linux, every sensor should have its own thread and the Linux scheduler should handle the scheduling. For more info on RT Scheduling, check [0] [1] [2].
As it is today, we're not even taking advantage of SMP (with the exception of some threads started by px4_task_spawn_cmd).

Let me know if I'm missing something, thanks.

[0] https://www.spinics.net/lists/linux-rt-users/msg16805.html
[1] https://www.spinics.net/lists/linux-rt-users/msg16808.html
[2] https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic

Macro inconsistencies

40ec861 changed the macro __DF_LINUX to __LINUX. Bebop uses __BEBOP. Darwin uses __DF_DARWIN, and for nuttx there are multiple, even some __PX4_NUTTX.

So what should the convention be? @julianoes

Also: the macro should be defined in cmake/toolchains/, but within PX4 Firmware, these never get included, and thus these macros need to be defined in the Firmware as well, which is prone to error. Case in point: https://github.com/PX4/Firmware/blob/master/cmake/posix/px4_impl_posix.cmake#L201, which should now be __LINUX.

/dev/ access

Hi!

This is more of a question, than an issue. It's not exactly clear from the example, whether /dev/gyro will be available after starting the framework. Can the gyro be used by another application by reading/writing to /dev/gyro, kernel module style?

Test failing on Mac OS

@mcharleb I get this output on Mac OS. Do you have specific pointers as how to debug?

Added driver 0x7fff538407d0 /dev/test0
TEST 1: readMessages
Read 3 messages
message 0: 9987
message 1: 9988
message 2: 9989
test PASSED (0)
TEST 2: read
Read 12 bytes (message = 4 bytes)
Read 3 messages
message 0: 20007
message 1: 20008
message 2: 20009
test PASSED (0)
TEST 3: ioctl
ioctl TEST_IOCTL_RESULT received
test PASSED (0)
TEST 4: Polling blocking read
Read 3 messages
message 0: 20010
message 1: 20008
message 2: 20009
Read 3 messages
message 0: 20010
message 1: 20008
message 2: 20009
test PASSED (0)
TEST 5: Polling timeout
Stopping driver and waiting for timeout
reading
timed out 60
test PASSED (60)
TEST 6: Read after setSampleInterval
start
reading
timed out 60
test FAILED (60)
tests done
shutdown

Fix collect logic in MS5607

@eyeam3 This fix went in for the MS5611.

bc07efc

Are you 100% sure you need a different driver for the MS5607? How do they differ? I would prefer to have this merged into a single driver. We're already in maintenance hell.

I suggest to start this work after #57 is merged.