-
Notifications
You must be signed in to change notification settings - Fork 340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High velocities due to the PX4Flow; making everything unstable. #97
Comments
Wouldn't it be more stable to store the integrated_data as integers (int16_t) with a fix resolution? With LSB = 0.1mm, the maximum speed would be 6.5 meters between two measurements. Then, convert the diff of the ints to floats on the FCU. Indeed, once the PX4Flow drifted a lot (due to invalid positioning) the LSB has a big influence on the float and we are loosing a lot of precision. |
This does not happen with #96 as we got a position fix all time. (drifting if too close of the ground, was around 15cm/s) |
@AlexisTM Isn't this rather a Firmware issue? What estimator are you using? Can you provide a log? |
As it happened each time when the PX4Flow was valid and went invalid for a long time (could be 5 mins) then was valid again, I would bet either on a PX4Flow integration error due to the high drift due to invalid data (integrated_x is a double, so when it goes big, it is imprecise) or a bug in the PX4 Firmware when the data is valid -> invalid -> valid again. I have no bag but I remember the behaviour: The velocities go up, (15 to 30 m/s) then down (-15 to -30 m/s) and it loops every 5 seconds. Once I took off without noticing it and the UAV went full speed straight to the wall. NOTE: I am not flying with the PX4Flow enabled outdoor. |
What is your exact setup? Usually the PX4Flow module just provides integrated angular rates (see http://mavlink.org/messages/common#OPTICAL_FLOW_RAD) to the Autopilot (PX4 Firmware). There the estimator uses the data to convert it to velocities using a distance sensor. So I highly suspect it is an issue with the estimator. Therefore I need to know what estimator you are using. And I don't need a (ROS) bag but a flight log from the flight controller (.ulg or .px4log). |
I have no log available for the moment as I am unable to get logs from QGC more likely because I changed multiple times of Firmware. |
@AlexisTM I see. Have you tried reading the logs directly from the sd card? |
I did not, but I have over 500 logs and I would have to find which one is bugging. I will try to replicate. EDIT: @ChristophTobler I got the problem, I will upload it ASAP |
@ChristophTobler Here is the log: https://logs.px4.io/plot_app?log=962b0f4e-3553-4ec2-b398-40258c9286e5 How: I moved it a bit at the beginning. Then I left the IRIS there for minutes then took it back up. To know if it was handheld or on the ground, just check the raw accelerometer ;) Bugs:
As I am always with a position with #96; It never happened. |
Thanks! Since this is a Firmware/estimator bug, I'll close this one. |
Yup, after seeing this log, I published the issue on the PX4 Firmware. |
Type: BUG
Firmware: PX4 1.6.5
Mavros: 0.19.0
Flow Firmware: Recent version from QGroundControl
We have this problem for some time now.
The PX4Flow works perfectly for some time, while it gets a position, but after a successful autonomous flight, we just let the drone on its landing position and the position (mavros/local_position/pose) goes back to 0 after some time, as expected. (Optical flow data not valid).
After 10 minutes, if we move the UAV again and the PX4Flow goes valid again, we have a huge risk of having inconsistent data. The velocities are huge (moving from -15m/s to 15m/s) in each direction and the position is messy.
It is not much reproductive, yet it happens often.
To avoid it, we have to put the drone back on the stand directly after the flight (allow the PX4Flow to be valid again).
If it happens, we reboot the Pixhawk.
Data example from the ~local_position/odom topic
The text was updated successfully, but these errors were encountered: