I’m getting strange airspeed data. Has anyone seen anything like this before?
I started out in airspeed calibration mode. Waited for 5+ minutes and noticed the airspeed ratio changed from 2.0 to 1.9. (Usually the ratio changes and I get a message about it in QGroundControl, but not this time. I had to look it up.) After calibrating, while still flying, I switched to ARSPD_USE = 1 and turned auto calibration off. Later the plane stalled and recovered, at 19m 40s into the log. It was dead calm as this was at 9:30pm so I can’t blame the wind.
Any idea why the airspeed data oscillates from the same fixed value to what looks to be the real airspeed value as shown in the images below? Seems very odd.
The wire is 40cm - 60cm long since the sensor is way out on a wind of a 2.5m motor glider. It is also twisted to try to reduce interference. Is that too long for I2C?
it is longer than usual, but whether it will work depends on other factors. Have you measured the pullup resistance on the i2c bus? It should be at least 1kOhm
I know how to measure resistance, but I’m not sure what specifically needs to be measured in this case. The cable is going straight from the recommended CA1 DA1 pads to the sensor. Nothing else is on the I2C bus.
Edit: I’m reading that 1k-4.7k resistor should be added between VCC and SCA, and between VCC and SCL.
Would I measure the resistance beforehand between the ports mentioned above, when the device is off? Not sure how to know how much resistance to add.
Here are the readings I’m getting for SCA and SCL. They seem ok to me. Does anyone see anything that is definitely wrong?
I’m wondering if the matek H743, which is known to to emit a lot of RF interference, is dirtying up the signal.
Here is the plane:
update:
I put two different sized chokes on the airspeed i2c line. Seems to have fixed it.
@tridge I just completed an autotune on Level 7 on 4.10 Beta 6 and when landed I noticed that servos are jittering. I am worried that they will burnout with such an intense activity.
Can I do something to relax them?
Edit:
I found a similar issue reported here: Shaking horizon and jittering servo's
BTW the video was taken on FBWA, on Manual it doesn’t jitter at all.
Thank you!
Edit #2:
Tested again setting INS_FAST_SAMPLE, 0 and the jittering continues.
Just in case is relevant these might have something to do with that.
Hi tridge, I made an upgrade from 3.9.10 to the firmware of FC
is 4.1 beta6.
after a short hover and landing, the compass begins to drift.
the video shows: https://www.youtube.com/watch?v=EVIYbLflCW0
compass calibration does not solve the problem.
Please help.
the log shows that you didn’t finish the pitch tuning. The roll tuning went fine, but you didn’t do enough pitch up/down to complete pitch.
You may still find you have some twitches on the ground even after completing pitch tuning. One thing you can do is lower PTCH_RATE_SMAX. I’d try changing from 150 to 100. If still an issue, try 75.
thanks for posting the log. The log shows two things:
your airspeed sensor did indeed change during the flight
the ARSPD_RATIO is very high at 3.6
The high airspeed ratio means there is a physical problem with the sensor even before the issue you hit in flight. It could mean there is a leak in the tubing, or could mean there is a “positional error”, which means the position of the sensor in the airflow prevents it from accurately capturing the airflow. This is often a problem with the position of the static port.
I don’t know what happened to the sensor at the end of your flight. Could you post a photo showing the install of the sensor, including the tubing?
Hello @tridge,
I really want to update my medium Quad plane (4+1) AUW 7kg, WS 230cm. It flies well using current stable 4.09. I want to do Autotune as you suggested in this thread but need advice. I Have simple questions:
1.After finishing Roll and Pitch Autotune, can I change mode to RTL for landing? I mean Does it Save the new PID setting? What is the proper way to do landing after Autotune?
2.Can we assume this FW 4.1 beta6 is the final beta that is safe to do a long mission? Or I should I wait for the Official Stable Release 4.1??
Thank you for your advice.
My best regards,
yes, it saves while flying, so just land as per normal.
I will be doing one more beta, but I am quite confident the current beta is safe. It does depend on your appetite for risk though - a beta is riskier than a stable release just as less people have tested it.
Thank you for your quick response… One more thing about AUTOTUNE., is it good to do roll first, and after 20X (or 22X), continue with Pitch 20X ? Is it safe for not using airspeed sensor at all for this quadplane with 4.1? (so far I don’t use airspeed sensor). I am looking forward to your last beta or stable release 4.1…
yes, also if you can see GCS messages then you will see a “Roll: Finished” message when roll is finished.
a good install of an airspeed sensor is better, but many people fly without an airspeed sensor with no issues, and no airspeed sensor is better than a badly installed sensor
@tridge
I think that is (your last statement) the proper statement … The reason for me not installing airspeed sensor… I hope you don’t mind if I have more questions and suggestion for a better UAV system…Thank you very much…
Thank you for checking it. So I reset the previous tune parameters and made a few changes based on what I’ve read. Completed autotune and it is much better but still a little twitchy so I will experiment with *_RATE_SMAX
Attached the log in case you are curious.
Important changes:
Applied ONESHOT_MASK for the servos
INS_FAST_SAMPLE,0
SERVO_AUTO_TRIM,1
Edit:
For last, with the NG being such a nimble plane I expect it to do 360+ degrees per sec, so I wonder what would it gain from a 10+ level autotune?
Thank you.
the maximum roll/pitch rate isn’t the limit - it is the phase lag, which comes down to servo speeds, control rod flex, surface flex, wing flex etc.
Note that you don’t need to actually retune to make it more responsive. Just raise RMAX and lower TCONST to get the effect of a faster response tune. The P, I, D, FF values stay the same.
I had a look at your log, and it is indeed quite odd. I can’t immediately see the cause though.
The easiest way for me to find the issue is if you can get a “replay log” showing the issue. To do that you would need to use the following parameters:
LOG_REPLAY=1
LOG_DISARMED=1
LOG_FILE_BUFSIZE=46
this will create quite large logs as it will be logging all the time but if you can reproduce with those settings and get a replay log then we should be able to use the replay log to work out what is going on.
ahh, actually, I do see one possible cause of the issue. The parameter COMPASS_AUTODEC is set to 0, disabling the use of the WMM magnetic field tables. That also disables the constraints on the evolution of the EKF earth magfield vector, which makes the EKF compass code much more likely to diverge. Is there some reason why you set COMPASS_AUTODEC to zero?
You also have COMPASS_EXTERNAL=1 for an internal compass (the LSM303D). That is harmless as the AHRS and compass orientations are both zero, but should be changed.
I have just released plane 4.1.0beta7, which I hope will be the final beta of plane 4.1.0 before the stable release. If no significant issues are found I will release 4.1.0 final in one week.
Changes since beta6 are:
USB log download speeds improved on F765 and F777 based boards (USB buffers increased)
Serial port DMA contention heuristics improved (reduces chance of delays writing to serial devices)
Declination automatic lookup rounding fix (caused inaccurate declination in some parts of world)
DShot (bi-directional) support on Pixhawk4, CUAVv5, CUAVv5-Nano
