Hello All,
I am using snapdragon and want to use offboard mode to implement takeoff behavior.
What I have is baro, IMU, optical flow modules.
I checked the log and found several problems.
First, with only baro available to correct z on the ground, the z_est[0] and z_est[1] were drifted about Ā±0.5 or so. After changed the baro weight to 3.5, z_est[0] is a little bit better, but z_est[1] is still bad. Further tests show that the acc[2] is not stable, sometimes with value more than 1. Is this expected? or any other reason for this issue? or any comments on the correction function,inertial_filter_correct?
Second, with bad velocity estimation, position controller cannot be performed well. Is it good to use only one position PID loop instead of two loops?
Any comments are really appreciated.
Thank you in advance.
Thanks Lorenz.
For better diagonise, I attached the accz output below.
This is the raw data from IMU after arming with propellers. I am not sure whether it is good to use before software filtering.
I wonder if the sin-shape vibration has any specific source.
Hi,
thanks for reporting this issue! Actually we are experiencing estimation issues on our side as well and at the moment it looks like it is related to the IMU data. We are in the process of reviewing the drivers and discussing potential filtering of the data. Will let you know what the results are.
Thank you tumbili.
I have used window filter to process the IMU data to Ā± 1 error.
Another issue is barometer, which seems have only Ā±1m accuracy with noise.
Further problem may be caused by the inertial_filter_correct function in position_estimator_inav.
I appreciate if you could share any results to improve this.
Thanks a lot.
When looking at the IMU data in the log or at the mavlink output in QGC, youāre only looking at 1 out of 32 for the gyro, or 1 out of 16 accel samples. The reason is that the MPU9250 FIFO buffer is read at 8kHz but the data is only published at 250 Hz.
Recent flight tests with ekf2 have been quite successful, however, itās not finalized what the filter/integration solution should be.
The baro needs to be covered with foam (permeable by air) to filter the effects of wind, orientation, copter movement, etc.
Also, it should not be directly exposed to sunlight.
Thank you Julian.
I added some output in the mpu9x50_main to see every output from mini-dm. The noise is from the resonance of the motors spinning. I tried several methods, from hardware to software. And my problem is that what accuracy of the accelerometer is good to use? like Ā±5m/s^2?
I found the barometerās problem as well. The spining of the propollers did have effect on the data.
If inav estimator is used, the parameters should be selected very carefully.
I will keep following this issue.
Thank you very much.
I donāt know exactly what data you can expect when using the mpu9x50. I am only working with the open source variant which is the df_mpu9250_wrapper and the mpu9250 driver of the DriverFramework.
Also, everything Iāve said above relates to it and not the mpu9x50.
In general, it is a good advise to use some vibration isolation/dampening of the sensor (Snapdragon board in this case) against the motors/frame.
The two effects to avoid are usually:
The full sensor range (+/- 16 G) is exceeded, therefore the signal gets clipped.
Aliasing occurs when prop/motor vibrations are sampled.
The red one is filtered data, with blue one raw.
My problem was whether this red one is good to use in the position estimator module? Since both the ekf2 and inav use the acc to predict the state. Large deviation make lead to bad prediction and I am not sure if the correction step could pull the estimation back to the good value.
Oh, and any filter would have a delay effect, does it matter?
I will try the new pull and test.
Thank you very much.
Hello @JulianOes
I did some more tests on Snapdragon flight recently. And the IMU problem seems better after I changed to higher freq and take average of 16 samples.
The remained problem is the estimation itself.
In the Atlflight version of PX4 firmware, there is no ekf2 module compiled. Moreover, in the ekf_att_pos_estimator module, there seems no optical flow topic subscription, which is what I am using to estimate xy position, so I have to stick on the inav modules.
I believe my optical flow info is correct, but the estimation of xy is not good enough. I wonder if it is good that optical flow can correct xy position, instead of only correcting velocity currently.
The code from ATLflight version is quite different from the master branch of PX4, do you think that is critical for estimation or control?
Thank you very much.
I bought the board from Intrinsyc and followed the provided instructions.
In the PX4 user guide from Intrinsyc, ATLflight version is written to be installed.
I did not know that PX4 master firmware also supports this board, since there is not any instructions besides some installation steps.
I tried to build PX4 on Snapdragon recently, but there are still some errors while running mainapp.
I will do more tests, but kind of confused which version should be used.
Thank you for your reminds so much.
@langxm1223 Hi Iām also working on snapdragon flight, we have built a quadrotor X frame, and can drive motors now. May I ask two questions, firstly, how do you connect battery to snapdragon flight board, and how much battery voltage you use. Secondly, have you tested use RC to control snapdragon?
Hi Sam,
I am also new to such board, so I think it is better that you try yourself no matter what I would say
First, the battery can be connected to the board via a battery distributor PCB, which can distribute the battery to esc, snapdragon board and other devices. The voltage depends on the size of your quad, e.g. 2S is for small quad.
Second, I can use RC to control the board to fly.
Both of these could be found in the guide files provided by Intrysc. However, I am not sure which PX4 you used, and still confused these different versions.
Hope this helps.
Thanks.
In case of damaging the board, we want make sure if the power module delivered by Intrinsyc can support 3S battery. The RC really has confused me. As you know, snapdragon send out PWM data via J13ās UART, we also want to send RC information to snapdragon via J15ās UART, but donāt clear about the MAVLINK frame format the RC information should be. If your snapdragon can fly, could you share your RC solution?
I have not tried 3S battery, so I cannot say it can support.
If you complied the PX4-Firmware version, it will send PWM via MAVLINK.
However, in Intrynsicās px4 user guide, the ATLflight version is used. In that one, the RC signal is sent out through some driver in DSP side. So I am afraid the you can try this version.
Thanks.
Thanks for your reply. I just reviewed the ATLflight code, rc_receiver_main.cpp is much straightforward than the PX4 version, if you can fly snapdragon flight stably, Iāll try it.
In the latest version of the PX4 User Guide from Intrinsyc (available from http://support.intrinsyc.com/projects/snapdragon-flight), we have updated instructions and a new release that incorporates EKF2. It uses proprietary drivers for RC Receiver and ESC but uses the open source MPU driver in the Driver Framework. The build procedure is slightly different from http://dev.px4.io, but we will replace our proprietary drivers with the upstream drivers shortly.
