Hello Chris,
I’ve attached the log file link.
The H_RSC_THRCRVs:
0 = 250
25 = 320
50 = 380
75 = 500
100 = 1000
Thank you very much for your help
Rotem
Hi Rotem,
From your log it looks like you’re using ~80% collective pitch to get it into the air. Probably due to headspeed a little too low. The throttle curve you are using is the default, more for piston engines. Electric has to be a little flatter.
So your current throttle curve looks like this. Note how the throttle increases very rapidly above 80% collective pitch. This is why it is so touchy.
You really should be hovering somewhere around 65-75% collective (from about 5 to 7.5 degrees of pitch). So let’s ramp the main a little quicker on the bottom end and flatten that curve once we get in flight to closer fit an electric motor.
I don’t know what your desired headspeed is, but typically electric drives like to be at least 70% throttle at hover or the ESC gets really hot. So let’s start out with a throttle curve that looks more like this
This will increase rotor rpm faster on the bottom of the collective, and not change it as much as you load the collective in flight. The settings for this are:
0 = 250
25 = 500
50 = 600
75 = 700
100 = 850
Now, if the headspeed is higher than you like, adjust the THRCRV 50 and 75 points down a bit. If it’s still not enough headspeed, adjust those up a bit. Once you get the headspeed where you like, now load it by slamming in full collective pitch and see what it does. If it “bogs” and loses headspeed, increase the THRCRV 100. If it over-powers and increases headspeed on a full collective punchout, then reduce the THRCRV 100 point a bit.
Basically, the THRCRV 0 is your ground idle speed you would like with the collective all the way down. The THRCRV 25 point will determine how fast it ramps up as you increase collective pitch. THRCRV 50 should be almost light on the skids and the head should be running at the speed you like - adjust accordingly. Between THRCRV 50 and 75 is hover and normal flight range - so you can adjust the 75 point so it holds constant headspeed as it goes from light on the skids to hover and general flying around. The THRCRV 100 point is your max power setting to maintain headspeed when you really put the screws to it.
Electric motors can make maximum torque at 85% throttle due to their nature. Piston engines can’t and require the throttle to be wide open to produce maximum torque. So that is why the curve for an electric will be a lot “flatter” than for piston or turbine engine heli’s.
Hope this helps.
1 Like
Hello Chris,
After long waiting for spare parts, I manage to perform a flight with your recommended setup and it worked perfectly!
The next step is to fix the tail wag.
As you can see in the video, the tail is waging and if I hit the throttle, the tail is undershoot, what can be the reason for that?
In addition, I would like to have the Heli more responsive to stick commands and make him fly faster, what parameters should I change?
Thank you very much for your support
Rotem
Could you export your current parameter file so I could take a look at it?
Thanks!
Hello Chris,
See in the link bellow.
Thank you
Rotem
Sorry, I’v uploaded the log file…
here is the parameters file.
Thank you
RotemTrex 700 param.param (14.3 KB)
You have not tuned your heli at all. In Mission Planner in the frame parameters you will find a TradHeli Copter3.6 setup parameter file. Please load that into your flight controller and see if it makes a difference in how your heli handles.
Hello Chris,
I’ve loaded the TradHeli parameters file and preform a test flight, unfortunately, the tail wags became worse.
In addition, I don’t know why, but after lending in loiter mode, the Pixhawk is tilting the swash plate to the right, causing the Heli to flip on the ground.
I’ve attached the log flight and the parameters file.
Thank you very much
RotemTradHeli 200618.param (14.3 KB)
https://we.tl/0Fary7Cs7b
Tail wag… Sometimes using the ESC governor mode (Such as 99.99% of full size heli) helps removing tail wag as tail rotor speed is quite high and has lots of authority… Just my 2 cents… 
Henri
I see tail bounce. Your vibes are right on the edge of being tolerable in flight - you’re getting some clipping of the IMU’s even in hover. And the heli is not going to fly decent that way. Part of the vibes could be coming from this:
Notice how you get a definite roll and pitch oscillation during runup. It’s normal to get some, but this looks like blades could be not tracking right, or the main rotor is out of balance.
I do not recommend taking off or landing in Loiter flight mode with a helicopter. Some say they do it all the time, and that’s good. But if you get a GPS issue you will likely crash your helicopter. You do not have any control of the heli in Loiter. The autopilot controls it and all you are doing is making requests to the autopilot to move it. This is a highly dangerous situation with a helicopter and I have a video as well that demonstrates what can happen when depending on the autopilot and GPS for takeoff and landing. I had to quickly switch to Acro flight mode here to get the heli to behave or it would’ve tipped over. Just a simple GPS glitch on landing caused it. And throttle hold was engaged and the heli in spooldown when it happened - it just had enough power left in the main rotor during spooldown to tip it over.
So I say use these augmented flight modes for takeoff and landing with a heli at your own risk.
This should be an issue against heli in github. We should do a better job of designing the loiter flight mode so it does not do this. I suspect I know the issue and hope to correct it as we are combing through the code to implement the spool logic. I believe this issue is the same reason that we had the collective jump in althold and loiter. The loiter flight mode was designed for Tradheli to continue to work with motor-interlock disabled and the aircraft disarmed.
So the mode is designed to set the desired position to the current position once it is landed with the motor interlock enabled and vehicle armed. Once the interlock is disabled the desired position is the left loose from current position. Thus the issue you had was that you experienced the glitch as you were landing and the land complete flag had not set. When you disabled the interlock, it continued to try to position the aircraft when in if designed properly should have relaxed the position controller helped the situation.
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.
That’s why I say “use at your own risk”.
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.
Hello Chris, Bill,
Thank you for your help!
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?
Thank you
Rotem
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
The whole problem is vibration the flight controller can’t handle.
@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.
Thank you
Rotem
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.