I’m using a matek optical flow and rangefinder for indoor position hold. With the correct settings the flow hold appears to work in loiter, but the altitude hold behaves strangely. When trying to takeoff I must give full throttle. If I take off in stabilize and then switch to alt hold or loiter the copter will descend. The only way to make it maintain altitude is to hold full throttle. After some time in this configuration if I lower the throttle the copter will not descend until I switch back to stabilize.
Looking at the log it seems like the altitude in ahr2 follows the barometer even though I have set the EK3_SRC for altitude to be the range finder for 1, 2, and 3. I have a log from a flight where this happens here. Any input would be welcome.
Hi.
I am not an expert, so I don’t know what exactly to conclude from what I found in the logs. So maybe someone will be able to explain what is going on here by looking at the list of some of the things I noticed in the log file.
Here are the things that I found unfit:
Your vibrations are not good. Even Clip is reaching 400 in the middle of the flight. So maybe try to reduce the vibrations.
Your Baro is giving a reading of about 2 meters, while the rangefinder is given a value of less than a meter. Also, the EKF3 estimator also closely agrees with the rangefinder. What was the actual altitude of this flight? I am guessing less than a meter, right? And if so, the prop wash might be the cause of the erroneous readings of barometer.
One of your motors (motor 1) is not aligned properly with the other three, making it to run slower than the rest.
Now, here is something that I find is most related to your query. As seen in the image below, the RCIN for throttle is at max for almost the entire flight. However, the CTUN throttle does not seem to be reaching “1.0”, not even nearby. Maybe some of the experts here might be able to comment on this.
Regarding your observations:
The vibrations on this are unfortunately inherent to the vehicle, but I am doing my best to remove as much as I can!
The actual altitude was less than a meter. The Flight was indoors and unfortunately there is an AC blowing down into my testing area as well. Overall I don’t think the barometer will be that useful indoors for that reason as well as the propwash.
Motors can be ignored. This is a copter using over-under propellers and a custom output type so it’s running in the ‘USERCODE’ loop. You can see the motor output voltages and velocities in the ‘BLUE’ topic of the log
The last point seems to be my main issue. The altitude does not follow with throttle at all! After a few flights it seems that it will get into the air and then no matter what I do with the throttle stick it will maintain a specific altitude. I can’t even land until I switch out of an alt hold mode!
Any input on the cause of this failure to follow the throttle stick would be wonderful!
My guess is that the ‘USERCODE’ loop is causing problems. Probably a control loop is not getting closed. Can you move the motor changes to lua scripting?
Hmm I might be able to. I’ll definitely look to see if it’s possible to move it over to LUA. The control loop is still the normal control loop from copter. The only thing in USERCODE is the motor output functions. The inputs to these are from motors->get_roll/pitch/yaw/throttle. I’ll check if there’s some loop closure I’m missing though! Are there any good examples for lua scripting that you’d recommend for this? My usercode is basically converting those roll/pitch/yaw/throttle commands to something readable by the motor modules I am using and then sending it off as well as logging.
I also have some newer logs with a few changed settings (but the same or similar results) if that can help.
So looking at the logs again, the aircraft seems to think that its vertical velocity is not 0, even though the derivative of the altitude is around 0. So the aircraft constantly thinks its going up for some reason. I guess I’d need someone who understands the EKF well to debug this?
