While working on my Bix3, I discovered some unexpected behaviour. It might be a bug in Arduplane 3.3, it might be me missing something.
Iām fairly new to building UAVās but I have quite some flying experience. I couldnāt imagine an aircraft not having an airspeed sensor, so I bought one (digital) for my Pixhawk. After configuring everything, with all gear still motionless on my desk and connected to MP, I noticed something strange: The artificial horizon is constantly moving in a range of about 3-4 degrees pitch. I disconnected all sensors to find out which one was causing it, and when unplugging the airspeed sensor the horizon was steady again.
I reconnected it to do some testing, these are the results:
The airspeed is fluctuating between 0 and 2-3 m/s, which is normal. However the pitch as indicated by the horizon in MP fluctates in the same pace.
When I press my fingertip on the pitot tube to simulate about 15 m/s speed, it momentarily indicates a pitch up to almost 10 degrees pitch.
When it reaches 15 m/s (I kept constant pressure so the 15 m/s didnāt change) the pitch returns to 0 degrees and it does not fluctuate anymore.
When I take my fingertip off the pitot tube, the horizon shows a pitch of about -10 degrees. After a second or so, the situation as described under point 1 is experienced again.
If I keep the box āEnable Airspeedā ticked in MP, but untick the box āUse Airspeedā, it is also steady. The airspeed still fluctuates as normal but the sofware doesnāt use it anymore. Of course this is not what I want.
My conclusion: When the measured airspeed increases, the pitch as indicated by the horizon in MP increases, and vice versa. This seems very strange behaviour to me, since the Pixhawk was motionless on my desk, so the gyroās shouldnāt detect anything other than a constant 0 degrees pitch.
Thank you for your reply. Iām right now looking into the whole logging function. I will provide you with a tlog and/or dataflash log as soon as I found the correct ones. Is it possible to send it via email / PM? I donāt want everybody on the internet to find out the exact place where I liveā¦
I found the tlog, and apparently because I was testing I disconnected the GPS, so Iāll just link to the file in this post. During the test the aircraft was on my desk. You can see the pitch move during airspeed changes (of about 2 m/s), and at 11:01 onwards you can see me increasing and decreasing the airspeed a couple of times. I have made a screenshot of this part of the graph.
What I did to simulate changes in airspeed: I taped a piece of foam wrapped in airtight plastic to the pitot tube, making sure it was quite a constant airspeed of about 20 m/s. I then squeezed the dynamic pressure tube between my thumb and index finger to increase airspeed.
You can clearly see that during āaccelerationā the horizon shows a pitch increase and during ādecelerationā the horizon shows a pitch decrease. Around 0 airspeed you can see the pitch moving with the airspeed. During the moments of near constant speed (around 20 m/s) the pitch is very stable.
Your pitch behaviour is strange. I have bench tested and can see similar to what your seeing but the pitch to a MUCH lesser degree. With my bench setup I first calibrate the air speed sensor. After this my airspeed fluctuates between 1 and 2. As I have no GPS lock due to be indoors the autopilot uses the airspeed sensor for movement. Thus as its registering between 1 and 2 my plane is slowly moving along the map. This is all standard behaviour.
However, after calibrating I see my pitch (and thus the HUD) fluctuate between 0 and 1 degree. If I cover the end of the pitot tube as you describe I see the air speed rise and if I hold it on I can get it up to 22m/s! But during that time the pitch still remains the same.
Its probably the accel correction due to the perceived acceleration coming from the airspeed sensor.
Note your TRIM_ARSPD_CM is set to 0. You should set that to a target airspeed in cmās/s second when you go flying - perhaps 1600.
Your TECS_SPD_OMEGA is set to 1. Did you change it from 2?
You have the EKF turned off - AHRS_EKF_USE is set to 0. Try turning that on and see if it changes the behaviour. I turned it off on my bench testing however nothing really changed but its worth a go.
In summary Iām not sure why your pitch is changing so much.
Thank you for looking into this problem. Iāve tested the aircraft including all sensors outside, and armed it. Mabye because it has a GPS fix/connected, I no longer see a large pitch movement when applying pressure to the pitot tube. Pitch does move all the time between 0 and 1 degrees as you described. Maybe because the GPS speed fluctuates between 0 and 0.3 m/s? Of course this is workable, however I still donāt get why a complete motionless board indicates a pitch change when the speed (air or gps) changes. Does this have to do with the accel correction you mentioned?
I have flown the aircraft once without Pixhawk, but I havenāt since I put all the electronics in. So didnāt start the whole tuning and (air)calibrating process yet. I will adjust the TRIM_ARSPD_CM to 1200 now. (1600 seems a bit fast for a Bix3?)
By reading trough the params before, to see if there was something I could do, I came across the TECS_SPD_OMEGA, and I tested the minimum and maximum valueās to see if it made a difference. Afterwards I forgot the default setting, but using Google I found it should be 1. Clearly it must be 2, I will change this as well.
AHRS_EKF_USE was indeed turned off. I was planning to use it but did only want to do so when I reached this part of the tuning guide. Do you recommend to turn it on from the first flight onwards? I have done the Accel Calibration before I put my Pixhawk in.
At least for testing Iāve now turned it on, and the pitch seems to be more stable. But indoors without GPS fix it makes no difference, still large pitch changes with airspeed changes. By enabling the EKF I do have another problem, it now sometimes gives me a bad AHRS alert on booting the Pixhawk. Maybe because it moves slightly when I connect the battery? I canāt prevent this and as the external compass is on my canopy, connecting the battery is allways a bit of a problem because I need to close it quickly to prevent a error compass variance alert. Is it possible to put a delay of about 30 seconds after boot for the preflight checks?
I have tested the Bad AHRS problems a bit more. I re-did my compass calibration and turned off the auto-declination setting as in this topic: viewtopic.php?f=105&t=11303
It doesnāt make any difference, the Bad AHRS message stays and I cannot arm plane. Even if I do the PREFLIGHT_CALIBRATE via MP, or reconnect battery and leave the canopy off so I donāt move the aircraft, the Bad AHRS returns. Also the pitch becomes unstable again.
The only way to make it work: AHRS_EKF_USE to off, repower the Pixhawk, wait for all messages to disappear, then AHRS_EKF_USE to on. This results in a very stable pitch indication and no Bad AHRS message. Unfortunately, after every reboot I need to repeat this.
Update 2: The more times I try, the more Bad AHRS messages I getā¦ Even if I enable EKF after boot now, I get the alerts. With EKF disabled I didnāt get any messages (I got the slightly unstable horizon again) however after trying to arm it told me: inconsistent accelerometers. I re-did the accel calibration with the Pixhawk in the aircraft. (I assume it is now less accurate since I did the first calibration very thorougly on a horizontal surface using a square tool to keep it straight.) Now it doesnāt give me the inconsistent accelerometers message anymore, but when I enable EKF, straight into the Bad AHRS message again.
I have had Bad AHRS intermittent problem every since I installed 3.3. If I power up and down a time or two it always clears. My experience is if you wait until you have 7 or more satellites then cycle power it is more likely to work and sometimes it will clear on itās own.
I have a couple of years of flying on this airplane and have never had this problem with any previous version so itās obvious to me that there is some king of a bug in 3.3. Hopefully 3.4 will get this all sorted out.
Thanks RC Mike. It is good to know that it could well be a problem in the software, and not with my particular setup. I will keep troubleshooting it but for now Iāll wait until a newer version comes out.
Hello, Digging up an old thread here, but has anyone found a solution for this? I have this issue with my new H743 with ASPD-4525 airspeed sensor using the i2c though the M8Q-CAN UAVCAN. Horizon is perfectly stable but as soon as arspd_use = 1 then the pitch starts to wobble a few degrees. in stabilized modes the elevator is moving to compensate even though the plane is sitting stable on the benchā¦ any ideas?
I am observing this same problem. Surprised to find a thread about it. As soon as I attach a digital airspeed sensor to my Matex F765-Wing the pitch jumps around 10-20 degrees at power up. Just sitting on the bench. Strangely it seems to settle down after 30 secs or so.
I fixed this by selecting a different (better) 5v and GND source for the sensor. I switched to the +5 and GND that I used for the GPS (which also has the I2C compass device) and problem went away.
Iām having the same issue on 4.1.2 with a pixhawk 4 and the px4 airspeed sensor. Why would airspeed have any effect on pitch and roll? Is the sensor so bad that it is inputting this level of noise onto the 5V?
I have a new pixhawk 4 running plane 4.1.6 with only the airspeed sensor (and usb to mission planner) plugged in. I am powering the sensor with a bench supply and whenever it is on the artificial horizon jumps around. Raw sensor view shows the accel stable. Airspeed moving 1-2m/s. When I cover the holes I can get the airspeed up to 8-10m/s and the pitch down is about equal to the airspeed. Below is a log where I turned on and off the airspeed as well as made it change value. 1 12-31-1969 4-00-00 PM.bin (468.3 KB)
I agree itās puzzling. Seems that the I2C device confuses the IMUs. I thankfully resolved the problem (with my Matek F765-wing) as I posted above. The fact youāre having it with a Pixhawk makes me wonder if thereās a software gremlin somewhere.
When I was seeing this error, I can confirm that I did see the horizon on MP from the EKF solution, and I did see it move around considerably, and randomly, like 10-20 degrees. As I posted earlier I am not seeing this error any longer so couldnāt reproduce it for testing nowā¦
but using Google I found it should be 1. Clearly it must be 2, I will change this as well.