So yesterday I upgraded to the new 1.4.1 firmware, and immediately encountered some serious issues. I took off the copter in stabilize mode, and after flying steady for 20-ish seconds, it veered out of control and hit a wall. After disarming, I held the copter level, and the QGC screen displayed that the copter was nowhere near level (looked like it was pointing at the ceiling, and it was changing (copter was not moving). After about 6 seconds, it displayed close to level, then continued drifting past that point. After a while of random drifting it seems to level out, but then goes crazy again as soon as I moved it.
I flashed back to 1.3.4 and can fly without a problem.
Hardware is RTFhawk, using the px4fmuV2 in both cases.
Here is a sample log with the issue, notice how the accelerometer values are all over the place, with a range of [5,5]. Keep in mind that I’m not flying in Indiana like the map says, is that another glitch?
Here is a sample with the older firmware flashed(no issue). Keep in mind that this 5 minute flight did not go from Indiana past the tip of Africa (another glitch?)
Any idea what’s going on here? Seems like a firmware issue. Would really like to get on 1.4.1 as I hear a lot of issues I’ve been having have been addressed.
This problem doesn’t seem to occur yet with the beta version uploaded – although I am seeing a problem that I haven’t seen in a few days ( I thought it was hardware, but it’s strange that I saw it until upgraded to 1.4.1, and then it came back again). The problem is that one of my motors shuts off mid-flight seemingly t random. Checked for loose connections and possible shorts but haven’t found any. Here’s a log of the beta flight, where the motor shut off. As you can see around 63.5 seconds in, the motor #4 PWM shoots up (to compensate), and looking at ATTC.Roll and pitch, it seems like the command to roll/pitch came after the moment where the motor was killed.
You seem to have very high vibrations just at the point where it sometimes still works and sometimes it diverges. Could you look into the autopilot mounting?
It’s mounted very rigidly using mushroom velcro to a DJI Flamewheel 450. Which log were you refering to about the vibrations?
My mount is no different from previous logs where I didn’t have these problems.
Here’s one of my “normal flights” for reference. This log is from the previous firmware where I was flying normal in manual mode, but Optic flow Pos. Cntrl was drifting.
Essentially what changes slightly between 1.3 and 1.4 is that the position hold performance has increased, but the system requires better vibration isolation. So what you need is to mount the autopilot on foam blocks.
Alternatively you can change back to the old estimator (INAV), using the estimator selection parameter in the Systems group.
Ok – But this problem did not occur during position hold, I was in manual mode. The problem is that copter starts off level, then mid flight begins to think it is pitched forward (up to 90 deg!) when it is actually level.
@LorenzMeier, Thanks for the tip, I’ll fix the vibration. Although that may cause problems, I don’t think it’s the cause of this issue. It could be a hardware problem (bad sensor), but maybe it’s software since the problem seems to only appear after a few minutes of flying, and it stops after I pull the battery and restart.
A little more detailed description after some investigation, and collecting more logs:
After flying without a problem for a couple minutes, my copter suddenly pitches forward, and I land it and disarm it (log). I look at my QGC console and see that the copter thinks it’s pitched so far that I can’t see the horizon on the screen, when in reality it’s sitting on level ground. The screen is slowly getting closer to where it looks like the copter is level.
I then arm the copter to record data in this log. While armed, I grab it in my hands and give it various impulses to see what happens with the horizon while I move it away from level. What was most interesting, was that when I was looking at my computer and holding it level, it was trying to pitch forward (towards computer), and when I turned around 180 degrees, it was trying to pitch backward (still towards the computer). As if the gyroscope was always pointing in one direction regardless of the copters orientation. Looking at the above log, this data can be confirmed by looking at the period between 90 and 170 seconds, during which you can see that as I steadily yawed the copter by hand, the gyroscope output would oscilate from 0 to 1 with the same frequency.
I’m thinking it might be a defective gyro, or maybe the new update isn’t compatible with the RTFhawk installed on this copter? I’m about to try it on a genuine V2 Pixhawk and see if I can replicate the issue. Any thoughts of what could cause this, or what further tests I should run?
use the analyze widget in QGC to look at your gyro and accelerometer signals while disarmed on the bench. They should correctly indicate the direction of acceleration and rotation rates while you move the copter around. If not, then you have developed a hardware problem, or there has been a firmware change which exposed a design flaw in the RTFhawk.
I was pretty convinced that it was a hardware issue, until today. I threw a genuine PixHawk 2.4.8 on my frame running 1.4.1dev, and after a couple minutes I got the same problehttp://logs.uaventure.com/view/Di4qxUzmcAqsYWx6usA5Bim. What I noticed from the first flight (log), was that it was flying fine for a few minutes, then suddenly pitched forward, and the QGC screen showed that it was not level (same symptoms). Once I landed and disarmed it, it slowly came back to level. Then I tried to run it while holding it in my hand (log), and the screen started again showing that it wasn’t level.
Clearly it’s not a hardware problem, as it’s persistent for both devices. Another thing to note is that I’m using the same airframe mixer on both Pixhawk (DJI Flamewheel airframe config), and I dumped the parameters onto the new pixhawk (it won’t let me upload my params here because it’s not an “authorized file extension”.
@LorenzMeier, this looks like a software bug that should be addressed. I’m happy to test more, and help try to figure out what’s causing it, but I’m not to familiar with the PX4 firmware and where the bug may lie.
@Mark_Whitehorn, the logs I provided should have enough information, and what I saw on the QGC screen (non level when copter was level) is just a graphical display of the data you’re talking about, if I understand correctly. I can upload the mavlink log from QGC if you think it would have more information (although as above, this page won’t allow me to attach it.
Hey Mark,
Interesting: It says 1.4.1dev in the QGroundControl info view, but I thought I uploaded the release version (I never hit advanced options).
As written earlier (logs for all these flights in the posts above), I tested with the release version, the beta version and an earlier (1.3.4) version. When I tested with 1.3.4 I could not replicate the issue, though it doesn’t seem to happen right away even when I can replicate it. I find that it usually starts around 2 minutes after I start flying.
Right now I’m about to wipe the parameters, and see if the issue persists, and if that doesn’t do it I will try to switch out of the preset Flamewheel airframe.
I realized that when I uploaded my old parameters to the new board, I overwrote the calibration. Recalibrated everything, and so far so good (two flights with no issues).
I must say I have very similar experience with 1.4.1 for our VTOL in quad mode. Loading the PID’s from 1.3.4 almost broke the wing from oscillations. Using the default gains for 1.4.1 gave somehow better results but still very very bad performance in Position. In 5-6 m/s wind something that was brilliantly flown by 1.3.4 now I had uncontrollable moments. The craft started drifting over my head backwards (facing the wind). During this moments i almost lost control on couple of occasions. It felt like the sensors are clipped and flooded at some points.
I will start PID tuning from scratch with this 1.4.1 and see if it performs better this way.
