There could be more to it than that, as I also got an EKF switch at that point due to the GPS glitch. And the EKF switch involved a different attitude solution.
I have since pretty much figured out this is more of a hardware issue than in the code. If the IMU’s aren’t consistent it seems to cause a quite radical attitude adjustment when the EKF processes switch. And there is not a lot we can do with that. ArduPilot is depending heavily on the GPS but is not as advanced as some other autopilots in this regard. Like some autopilots that set an angle in the sky where the GPS receiver won’t use any satellites below that angle if the altitude is below a certain value. The Skookum SK-900 and SK-1000 helicopter autopilots use this method to prevent GPS glitching and position error on the ground. As glitching is normally caused by low incidence signals multi-pathing from being reflected, or diffraction. NVIS signals help prevent this.
You can read thru the forum about flyaways during auto-landing, etc - all related to GPS issues. This is going to be an inherent problem with using GPS modes close to the ground. As GPS is not 100% reliable and has limitations. Since especially large helicopters can be quite dangerous under autopilot control with a GPS glitch or issue, and those issues are easily 10x more likely close to the ground, I have problems recommending its use with heli’s in critical flight stage of air to ground transition.
Yes That would be a problem. I had forgotten about that.
I thought you recently discovered that you were running two EKF solutions. EKF_IMU_MASK was set to 3. I looked at my param file and am only running 1 EKF. Would I still be in danger of getting this EKF switching?
Ok so I get the hardware issue. Reliability is necessary to ensure consistently safe operations. Also GPS glitching is possible. It wasn’t until recently that I had experienced that. However I have been flying multicopters for almost 3 years and have not seen this type of behavior. I totally understand the dangers involved with heli’s on the ground but I believe that we can make an effort to minimize the risk.
In looking through the code for inconsistencies between multi and heli, I noted the issue I explained in my previous post. So this difference in the design of the loiter logic is concerning to me and like the collective jump issue, I think it needs to be fixed. My question is why the logic was designed this way for tradheli in the first place. I’ll post the issue in github so it can be tracked until we determine whether it should stay or be changed.
No doubt. users should always be ready to take control and switch to stabilize mode, regardless of multi or heli. We have not achieved the system reliability that gives a user confidence that the system would respond in a safe manner to failures.
On my problem boards it seemed to fix it by setting that to 1. I don’t know how mine got changed to 3. It’s been that way in every saved param file I have back to the beginning of 3.5. The docs say the default is 1. So it’s possible I changed that at some point and it has just carried forward every time I put in new firmware.
I agree if there’s a way to make it better we should. Does it indicate in the history of the file who originally designed the logic that way? That might be a quicker way to find which developer designed it that way and ask direct.
This is totally a personal preference. I have experienced the dangers of relying on the autopilot too close to the ground and don’t use it that way. And I’ve never had an issue except when deliberately testing new firmware, and then it happens, and it’s a good reminder (to me) as to why I’ve developed my “method” of doing all my pre-auto mode checks before I’ll let the autopilot take over.
Auto landing I just don’t trust because of many of the areas I take off from on commercial flights. Sometimes I have a nice road with a lot of room. Sometimes my pickup is parked alongside the road and I have a field drive with about 6 feet square, fenceposts only a few feet away, public road on one side, a crop of some sort on the other, and powerlines directly overhead. I just don’t trust the accuracy of the system is going to put a big heli back in that square autonomously, while missing powerlines by a couple feet, without wadding it up.
If you’re out in a open field with no obstructions around, no powerlines overhead to mess up the GPS and compass, and lots of room if the accuracy of the system is less than stellar, the landing detector does work pretty good.
Can you please advise what is the “normal” oscillations (I can see numbers between 0 to 5 and -4 to 4, what is the meaning of these values)?
The flip over issue happened only after loading the TradHeli parameters file (two flip overs out of two flights in loiter), all other flights (5 or 6) with the default parameters was landed without this issue, therefore, I will try to reload the default parameters file and check it again.
I don’t know if it’s related but at the default parameters, while I’m checking the throttle on the ground without blades at around 3/4 to full throttle, the swash plate is tilting hard right and level again after lowering the throttle to mid to zero.
At the TradHeli parameters the swash plate is leveled only after the throttle is at zero.
I don’t know it it’s coincidence or not or if there is any importance to it, but I will check it again.
The reason that I’m not changing flight modes in the air (Stabilized\ Loiter) is because I’ve read that the Heli can “jump” hard up or down if the throttle stick position at hovering is not synchronized between the two flight modes, so I think I need to do it soon, what is the best way to do it?
I would think this is very likely related to vibration. The IMU’s are not coping with it and the attitude solution goes bad.
The tuning parameters put a different “tune” in the heli that likely changes the frequency of the vibration to a different spectrum that causes an issue on landing with extreme aliasing of the IMU’s. If you look at your log note the clipping goes off the chart on the primary IMU when you land, which causes the EKF to switch. And that will tip the heli over
@bnsgeyer if you look at the param file for this heli the EK2_IMU_MASK is set to 3? Is that the default now, despite what the documentation says?
EK2_IMU_MASK,3
This is a good demo of what I recently discovered where the IMU’s are not the same (even with good vibration damping), the EKF switches either due to aliased IMU’s, gps glitch, whatever, and the heli goes wild. If the two IMU’s agree the EKF can switch and it doesn’t affect it. I found this testing the dev edition Pixhack V5 controller. The IMU’s in that thing are the best I have seen and it can handle a EKF switch and you can’t tell it happened. Right here is the problem.
So the solution for the EKF switching is what?
I’ve read about the trex 700 vibration and it seams that it have a problem with the tail drive mechanizm… maybe it’s not a good frame to start with.
I’m using Pixhawk 2.1.
You can try setting EK2_IMU_MASK to 1, that prevented it on my PH2.1.
The other thing is to get the vibration as low as possible. I don’t think it’s tail drive from the looks of your log, although it doesn’t hurt to take the torque tube out and put three bearings on the shaft instead of two. It looks more like, from the frequency of it, blade imbalance. This can be caused by blades not tracking (usual cause), blades out of balance (not likely with good quality blades), or blade lead/lag from not having the lead/lag hinges (grip bolts) set right. The bigger the heli, the more important proper adjustment of the lead/lag is so the the blades lead/lag the same amount.
Your heli has a semi-articulated head and there’s more to how it works than just blades “flying out on center” when it spins up.
Full sized helicopters have lead/lag dampers. Our RC ones don’t (unless you get a really expensive scale head). So here’s a sort of a good tutorial on how they should be set on RC
Once you know you have that set right, it’s easiest to track them by hovering it and use like red and green bits of tape on the blade tips and have a helper look at the blade disc edge-on in hover. The two blades should be on the same track. If they aren’t adjust the pitch links accordingly a half turn at a time until they track right.
And even then in full-size helicopters we’ve found when using the DynaTrak to track a main rotor that blades perfectly tracking don’t always yield the lowest vibration. So it doesn’t hurt once you have it tracking to try going a half turn either way on one blade pitch link to see if you get lower vibration.
A clip is basically an error for the IMU (gyro or accel) because the vibration is so high it can’t properly measure the attitude or acceleration values of the heli. The clip graph must be zero at all times. You shouldn’t get any clipping at all.
A short flight in stabilized mode after disassemble the TT (was bent a little bit for unknown reason) and adding dumpers to the Pixhawk.
Fly much better, much less tail wag, only delay in compensation but I think the tail servo is too slow.
In addition, I don’t understand why the clip is rising after lending…
Definitely not as bad as it was. Still a little hairy on the Y-axis for vibes though. Obviously thing is vibrating pretty bad on the ground to make the clips go up like that.
What are you running for headspeed? In my experience Trex helicopters like lots of headspeed to fly right.
Don’t know what is the head speed… I’m not using governor and the RPM sensor is not connected yet.
I will replace this frame… I will look for more suitable frame, do you recommend one (lighter, lower head speed, with less vibration issues)?
meanwhile I will use it to learn the Pixhawk on Heli
My personal favorite is the big Synergy heli’s. But they’re not lighter - they’re built like a tank.
There’s nothing wrong with the Trex - they’re just a light built very well balanced machine so they’re super quick. With a few modifications they make a pretty good UAV heli - either put on bigger tail blades (if you’re running low headspeed) to give it the tail authority, or change the gear ratio on the tail box. In the later Align models they made it not possible to change the main transmission or tail ratio - one downside. They just like lots of headspeed to stabilize them properly.
