Add BMI270 driver, and support for KakuteH7v2 and KakuteH7mini #20545
Conversation
|
Thanks, I am glad to see progress on this! I built and upload this to a Kakute H7 Mini V1.3 but the sensor is still not detected. |
| if (res == PX4_OK) { | ||
| RegisterWrite(Register::CONFIG1, 1); | ||
| PX4_DEBUG("Successfully uploaded initialization file onto BMI270"); | ||
| px4_mdelay(150); |
There was a problem hiding this comment.
In general we try to avoid having any sleeps in these drivers because they'll completely block the bus (which is often shared with other sensors).
An mdelay(150) on NuttX is particularly bad because it will just spin for 150 milliseconds and starve everything lower priority.
|
Thanks for finishing, this mostly looks good other than a few problematic sleeps. Do you have any testing? If you can share a ulg (even from the bench) I can do a quick sanity check. |
|
@dagar @arguelle thanks for the prompt feedback. Made a new KakuteH7Mini target, and it should now work (with caveats) on the Kakute H7 Mini V1.3. I also have a MPU-equipped V1.1 on hand and will test when I have time. It seems though that the BMI270 doesn't initialize by itself even though I've listed it in With regards to the sleep code, I had a go at replacing In the long run I'd love to get the W25N01GV NAND flash on the V1.3 working. However unfortunately there doesn't seem to be NuttX drivers for that particular model of NAND flash, and my bodging using the included W25N driver (afaik a NOR flash driver) didn't work. Some guidance on getting that sorted would be great, as otherwise this board can't log apart from ulog streaming via MAVLink - which works quite alright with an ESP8266, providing ~24KB/s of throughput. Please find the bench test ulog file here: https://review.px4.io/plot_app?log=9fdafdf1-b591-4b19-86bb-7e30fa85c769 |
ScheduleDelayed isn't a sleep, it schedules the next work queue cycle. That's why the main driver structure is a simple state machine. You set the desired state, schedule the next run, and leave (so other things on that bus can run). |
|
I managed to get the IMU working with your new target in de47855 I do lose RC for a moment when I load the driver though. In addition, in the calibration I have to set 270_deg yaw even though my FC is mounted with 0_deg yaw. I am excited to get flying soon :D The latest commit does not work for me. When I load the driver the CPU usage goes too high and I get error messages for the gryo/accel (see image). It also makes my RC unreliable. Also, as of 0e2b1ee my Kakute H7 Mini V1.3 no longer responds to the request for params. Is this worth opening up a separate issue for? It seems to be a Mavlink related commit. |
|
Replaced the delays with a new state for loading the microcode. The sensor still doesn't start automatically though, can't see anything else apart from @arguelle there is a hardcoded rotate in the sensor driver that accounts for IMU mounting, that could be wrong. Will test and check. |
|
@dagar any thoughts on why the driver won't start automatically but starts fine when I do it via nsh? |
|
@j-chen-opteran. As for the rotation problem, maybe you can try As for the auto-start of the imu, maybe you can exchange the sequence of bmp280 and bmi270 in |
|
@j-chen-opteran Maybe the spi is not well initialized in |
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
05c8d40
to
0f4c9b5
Compare
|
@j-chen-opteran I hope it's ok that I've rebased this and added a few commits to make it work on the Kakute H7 V2. |
|
I noticed that the accel calibration doesn't work yet, presumably because the scaling on the y axis doesn't look right. While the values in x and z are between -9.8 and 9.8 m/s^2, the values in y are between -14 and 14 m/s^2! |
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
0f4c9b5
to
c8bfcad
Compare
|
I've added more commits, fixing zeros in gyro/accel reads, as well as the temperature. However, the range in the x and y axes is still wrong. @dagar have you seen that before? Basically values between -14..14 instead of -9.8..9.8? |
Thanks for sorting this out! Does it start by itself on the Kakute H7 V2 without needing to do it manually now? Will have a look at the scaling again, there are some register bits that determine accelerometer scale and I'll double check. |
| if ! icm20689 -R 6 -s start | ||
| then | ||
| # The Kakute H7 v2 comes with a BMI270 instead | ||
| bmi270 -s start |
There was a problem hiding this comment.
I don't suppose there's any way to explicitly know if we're on a v1 or v2?
There was a problem hiding this comment.
@vincentpoont2 is there an easy way to check if we're on v1 or v2?
ver all says HW arch: HOLYBRO_KAKUTEH7
There was a problem hiding this comment.
@julianoes Physically, they look different, there is also silkscreen on the PCB.
Kakute ships with betaflight firmware, to use PX4, user need to flash PX4bootloader into it.
If they share the same bootloader I guess there is no way to distinguish them?
There was a problem hiding this comment.
I have created separate build targets and device_ids now.
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
c8bfcad
to
8e15da8
Compare
|
@j-chen-opteran and @dagar I've fixed the wrong accel range, check the last two commits. It turns out that the FIFO readout was off and contained some 0s which magically lead to correct values in the y and z axes because the accel range/scale was also wrong. |
julianoes
changed the title
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
d413850
to
c1b5697
Compare
| RegisterRead(Register::CHIP_ID); | ||
|
|
||
| // It takes 200us for the device to start SPI communication. | ||
| px4_usleep(200); |
There was a problem hiding this comment.
@dagar this is ok, right? It's just in the probe.
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
c1b5697
to
0c2a6ca
Compare
Instead of reading directly from the FIFO_DATA register, we read instead from the FIFO_LENGTH_0 register. That way we read length bytes before the FIFO data and hence didn't actually read enough data. This lead to accel y and accel z data be 0 every so often which ended up matching the range, even though it was wrong. (Spoiler: the range calculation is also wrong.) Signed-off-by: Julian Oes <julian@oes.ch>
Not sure where the range defines come from but they did not match the datasheet. Signed-off-by: Julian Oes <julian@oes.ch>
We now create a separate target for the KakuteH7v2. Signed-off-by: Julian Oes <julian@oes.ch>
There will be a v2 as well. Signed-off-by: Julian Oes <julian@oes.ch>
This syncs the kakuteh7mini target with changes that seem to have happened in the meantime. Also, we now use a separate target and device_id for it. Signed-off-by: Julian Oes <julian@oes.ch>
This is required because v2 comes with NAND flash instead of an SD card. By having a separate target we can handle that a bit more gracefully. Signed-off-by: Julian Oes <julian@oes.ch>
This seemed wrong before. Signed-off-by: Julian Oes <julian@oes.ch>
We have no SD card and no support for the NAND flash yet. Signed-off-by: Julian Oes <julian@oes.ch>
We have no SD card and no support for the NAND flash yet. Signed-off-by: Julian Oes <julian@oes.ch>
There is only NAND flash on this board. Signed-off-by: Julian Oes <julian@oes.ch>
There is only NAND flash on this board. Signed-off-by: Julian Oes <julian@oes.ch>
Signed-off-by: Julian Oes <julian@oes.ch>
Signed-off-by: Julian Oes <julian@oes.ch>
Signed-off-by: Julian Oes <julian@oes.ch>
We need to wait 200us after telling the device to initialize SPI. This change fixes the issue where the BMI270 did not initialize on cold boot. Signed-off-by: Julian Oes <julian@oes.ch>
Signed-off-by: Julian Oes <julian@oes.ch>
For some reason a comment saying "disable not set" enables it. Signed-off-by: Julian Oes <julian@oes.ch>
We should only start publishing once the there is actually data in the buffers. Signed-off-by: Julian Oes <julian@oes.ch>
|
I just tested flashing using QGC which worked fine for me, both on H7v2 and H7mini, with QGC latest stable release and a newer daily build.
When you get that. Are you sure you don't have QGC open which occupies the port? Or the other thing would be if the board ID of the bootloader doesn't match the firmware version that you're trying to flash. |
julianoes
force-pushed
the
pr-bmi270-fixed
branch
from
cddda16
to
51be84f
Compare
|
@dagar I think this is ready to be merged. I'm going to add the docs for it next, and then we need to make sure the links to the bootloader files are all correct. |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/kakuteh7-v1-paramters-not-saved/36845/2 |
Describe problem solved by this pull request
Following up on #20453, added code to read a BMI270 IMU at 1600Hz
Describe your solution
Based off the uncompleted pull request by @dagar, with some additional information pieced together from the datasheet and the Ardupilot BMI270 driver. Accounts for the fact that the data frames that the BMI270 outputs are not always the same length.
Test data / coverage
Tested and working with the Holybro Kakute H7 Mini V1.3, which is equipped with a BMI270 as well as a 1GB W25N01GVZEIG NAND flash chip in lieu of a SD card. A new board target is in the works that uses NuttX's SmartFS instead of a SD card driver, and will be pull-requested in due time.