only support body rate ctrl?

[dssdyx]

It's a very helpful project. I have test it but found that there is no orientation output,but body rate.Does it mean that when using RC controller, it will be like FPV or Acro mode? And if I want to use offboard mode, only the desired body rate is valid?

[Peize-Liu]

It's a very helpful project. I have test it but found that there is no orientation output,but body rate.Does it mean that when using RC controller, it will be like FPV or Acro mode? And if I want to use offboard mode, only the desired body rate is valid?

I think you mean orientation output is the data in the global frame like NED? Or do you mean orientation output is the attitude? if you want attitude data, you need to subscribe /imu/data rather than /imu/data_raw. The default attitude estimator is EKF2 in PX4, the output rate should be around 170Hz, and it will go to 200Hz after you set the attitude estimator as Q estimator. Without other sensors, Nxt can fly in Acro mode, Attitude mode, and altitude mode(the height estimator's performance is not good). If you want to control in offboard mode, you need /imu/data to get both acc&gyro data and attitude data for basic implementation. If your research is around flight control in high dynamic motion, from my lens, use /imu/data_raw and estimate attitude in your computer and then gives the direct angle rate control would perform better.
Hope it will help you.

[dssdyx]

It's a very helpful project. I have test it but found that there is no orientation output,but body rate.Does it mean that when using RC controller, it will be like FPV or Acro mode? And if I want to use offboard mode, only the desired body rate is valid?

I think you mean orientation output is the data in the global frame like NED? Or do you mean orientation output is the attitude? if you want attitude data, you need to subscribe /imu/data rather than /imu/data_raw. The default attitude estimator is EKF2 in PX4, the output rate should be around 170Hz, and it will go to 200Hz after you set the attitude estimator as Q estimator. Without other sensors, Nxt can fly in Acro mode, Attitude mode, and altitude mode(the height estimator's performance is not good). If you want to control in offboard mode, you need /imu/data to get both acc&gyro data and attitude data for basic implementation. If your research is around flight control in high dynamic motion, from my lens, use /imu/data_raw and estimate attitude in your computer and then gives the direct angle rate control would perform better. Hope it will help you.

Thanks for your reply. And I find that the problem is that the barometer bmp388 cannot be read, which results in ekf2 no running. I use v1.1.0 board,and I think the rc.board_sensors may have some mistakes, such as baro addr or others? Otherwise, v1.2.0 is reported, the sensors on board are also changed. But the rc.board_sensors is not changed. Would you update this file?

[Peize-Liu]

@dssdyx

To check hardware, use QGC, dmesg in the console; you can see the debug info

here you can see bmi088 can not be found because of soldering. For all my v1.1.0 devices, baro is functioning normally. I am still testing on the V1.2.x version hardware and have no available v1.2.0 hardware right now, so the new imu's configuration is not merged into develop. If you already have v1.2.x hardware, in Px4-AutoPilot, a branch named ' feature_test_icm_imu' is available, and SYSU's students have already tested it. There should be no issues.

[dssdyx]

@dssdyx

To check hardware, use QGC, dmesg in the console; you can see the debug info here you can see bmi088 can not be found because of soldering. For all my v1.1.0 devices, baro is functioning normally. I am still testing on the V1.2.x version hardware and have no available v1.2.0 hardware right now, so the new imu's configuration is not merged into develop. If you already have v1.2.x hardware, in Px4-AutoPilot, a branch named ' feature_test_icm_imu' is available, and SYSU's students have already tested it. There should be no issues.

OK. Thanks for your reply. It's the soldering problem.A resistance loss in baro module which causes MCU cannot read data. After resoldering, bmp388 works and ekf2 runs well.But I find that MPU6500 not initialized, if I want to use it, I need to rewrite rc.board_sensors. Could you tell me why not use this imu? Is there something wrong?

[Peize-Liu]

nothing wrong. It should be a mistake. I will fix it later.

…

On Mon, 5 Jun 2023 at 4:54 PM, dyx ***@***.***> wrote: @dssdyx <https://github.com/dssdyx> To check hardware, use QGC, dmesg in the console; you can see the debug info [image: image] <https://user-images.githubusercontent.com/54743766/241910280-65666df4-aa8d-4a84-b1ef-9ad98a7ab254.png> here you can see bmi088 can not be found because of soldering. For all my v1.1.0 devices, baro is functioning normally. I am still testing on the V1.2.x version hardware and have no available v1.2.0 hardware right now, so the new imu's configuration is not merged into develop. If you already have v1.2.x hardware, in Px4-AutoPilot, a branch named ' feature_test_icm_imu' is available, and SYSU's students have already tested it. There should be no issues. OK. Thanks for your reply. It's the soldering problem.A resistance loss in baro module which causes MCU cannot read data. After resoldering, bmp388 works and ekf2 runs well.But I find that MPU6500 not initialized, if I want to use it, I need to rewrite rc.board_sensors. Could you tell me why not use this imu? Is there something wrong? — Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANBVFVSUOLZKRZHA7DXVAPDXJWNFDANCNFSM6AAAAAAYKARRRU> . You are receiving this because you commented.Message ID: ***@***.***>