px4 / driverframework Goto Github PK
View Code? Open in Web Editor NEWOperating system and flight stack agnostic driver framework for POSIX (Linux, NuttX, Mac OS, QNX, VxWorks).
Operating system and flight stack agnostic driver framework for POSIX (Linux, NuttX, Mac OS, QNX, VxWorks).
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
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.
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
It would be nice if dspal_math.h also contained the float constants and not just the doubles.
There seem to be unit tests for the DriverFramework, however, I don't see instructions how to use them.
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
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 :(
Let's keep track about the unit tests on the respective platforms:
RPi1 | RPi2 | RPi2 | |
Navio+ | |||
Navio2 | MPU9250 pass |
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?
Document the magic nsh / mavlink switching by using an SD card or not.
This was raised by @Michvw.
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.
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.
Is anyone working on IIO support for Linux?
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.
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)
...
@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
@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?
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.
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;
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.
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 ?
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))
DriverFramework defects from Coverity.
You can access them https://scan.coverity.com/projects/px4-firmware/view_defects
Ping me if you need access.
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.
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.
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.
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.
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?
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?
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.
@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.
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?
The serial open call of the GPS currently leads to a crash if the HMC5883 driver is already running.
This needs investigation.
@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.
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?
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
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
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
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
.
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?
@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
We should support ESCs over I2C.
@mcharleb, @jywilson
When the write of i2c.c is used, this leads to different ADSP restarts.
This needs investigation and fixing to make the HMC5883 driver work properly.
It is not clear to me if this bug is just because there is a leftover printf in i2c.c (see #22), however, I've seen ADSP restarts just because of printfs, so I wouldn't be surprised.
It would be great to have support for the mag included in the MPU9250.
The driver is here: https://github.com/PX4/DriverFramework/tree/master/drivers/mpu9250
And the wrapper for PX4 is here: https://github.com/PX4/Firmware/tree/master/src/platforms/posix/drivers/df_mpu9250_wrapper
I suggest to start this work after #57 is merged.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.