Hi all,
I am getting close to working through some updates to the Attitude controller and I would like to make sure that I have considered the requirements of Trad Heli. As I don’t fly Trad Heli I am somewhat at a disadvantage. In particular I would like to understand:
Your before-first-flight tuning you do. In particular I am interested in any parts of this process that you use the Autopilot. Here I am not focusing on things like autopilot calibration, more things like servo travel and some of the advanced setup features of heli.
The ground check procedures people follow. For example, how do you check your swash is moving correctly. How do you make yourself comfortable the autopilot is working correctly. I would like to know exactly what procedures you use and what you are looking for as you run through them.
Your spool up procedure. Is it always the same or different depending on what mode you want to fly in. I would like to hear exactly what you do from just before your rotor starts spinning until a few moments after lift off.
Do you think there are any special cases that need to be handled in Heli?
My goal here is to understand what process people go through with Trad Heli and determine if the current controllers are able to be optimised for these needs. I would like to highlight where I can enhance heli support and where I need to add additional features to address short cummings in the controllers.
If you can demonstrate issues using video’s and dataflash logs I would be very greatfull. If you can’t do this that is fine too but please take the time to answer questions.
Lost yaw control caused by flying backwards until the tail swings around.
The current yaw error limitation is: 120 / angle_yaw.kP degrees.
We could change this to the angle that generates the maximum output to the yaw actuator. This would result in the tail swinging around and being set to the precise angle that the heli is able to take control of yaw again.
Other approaches would be to set a fixed maximum yaw error. This has the advantage of being easy to visualise and understand but may limit the aircraft’s ability to fight a disturbance. It may also result in a larger bounce back or side load in some cases.
I really need a dataflash log showing this effect if I am to be confident I am doing the right thing.
The changes that implement the start up behavior and air/ground transitions are most of the commits from April 15. The first one is my notch filter which you can disregard. I also implemented a pitch rolll and yaw error limit too if you are interested.
I added the shift methods to implement the attitude error leak while on the ground for pitch and roll and a method that sets pitch, roll and yaw to current aircraft attitudes. These are then used in the state machines that I implemented in the heli_stabilize_run and heli_acro_run routines to handle the unarmed, ground and takeoff swashplate behavior.
I offered up this software to @ChrisOlson, @ultrafuge and @Rob_Lefebvre. I’m not sure if they have any comments on it. i’m not trying to speak for the community but this is what I came up with. I’d be willing to make the firmware available for others to try and provide comment.
Hopefully my explanations and the software description make sense. Let me know if you have any questions.
I fly two different types of helicopters - flybar and flybarless. The procedure for tuning flybar is pretty simple; turn the rate controller for pitch and roll off (P,I,D all set to zero). Adjust ACCEL_Z_P to .3 (the .5 default will make the collective “bounce” on a helicopter). Set the VFF for pitch and roll so I get normal-looking swash travel. For a big helicopter (600 or bigger) set the ATC_ACCEL_x_MAX to 72000 for pitch and roll, 20000 on yaw. For a smaller helicopter I leave the ATC_ACCEL_x_MAX at default. Hover it and tune the tail rate PID’s, which only takes a couple short flights. And it’s ready to fly. I’ll do some auto flights with it at increasing speeds up to 30-35 m/s (piston engine) and adjust the flybar for stability. Electrics typically don’t have enough power to fly that fast sustained, so I top out at about 20 m/s for those.
For flybarless, my procedure is the same as flybar except for the rate PID’s. The tail is the same as flybar. I set the rate P’s for pitch and roll to where it becomes unstable, then move them back to where it hovers stable. Adjust the VFF to get normal looking swash travel with the sticks in Stabilize. Hover it and fly it around a bit and tweak the VFF until I’m happy with how it responds to stick flying. Then put it Loiter and adjust the I gain until it holds position nicely in the wind. The rest of the tuning is done in Auto flying, starting with slow speed flights and reviewing the logs. Increase speed on subsequent flights and adjust what’s necessary to make it stable.
Typical pre-flight is
-start the ground station software
-Turn on the transmitter and FPV receiver
-Set collective to mid-stick on the transmitter and verify all switches in pre-engine start position
-Boot the helicopter’s Pixhawk
-turn on the servo power
-turn on the FPV transmitter power
-On boot the swashplate should immediately go to approximately mid-travel and the servos should run thru their test cycle
-Move the sticks on the radio and verify correlation between sticks and swash/rudder
-Connect with the ground station and verify mission parameters (either upload or download from FC)
-Verify GPS status and HDOP
-Arm the flight controller, start the engine and let it warm up for one minute
-One final check of the “gauges” on the ground station and FPV link
-Engage the governor and clutch and start spooling up to takeoff power
-spoolup takes 20 seconds on my helicopters - observe for vibration, no strange noises, keep an eye on the main rotor TPP and adjust cyclic (if necessary) if the helicopter is on an unlevel surface
-verify spoolup countdown is complete (timer on the radio) and headspeed is normal (tachometer on the radio)
-feed collective pitch to hover collective, adjusting cyclic as required to get a smooth level liftoff, and start adding torque pedal (rudder) as necessary to counter main rotor torque.
-on liftoff gradually relax the rudder and verify the tail gyro has “kicked in” and is holding the tail.
-increase altitude to ~6-7 meters and engage Loiter flight mode
-one final check of the “gauges” on the ground station, visually check to make sure helicopter is holding postion, adjust my payload, FPV link and headspeed normal, enage autopilot.
@Leonardthall I have flown Bill’s changes to the code and they work as advertised for me in my FBL helicopter. I thought they were some very nice enhancements, and my wife (student helicopter pilot) also flew Bill’s code and didn’t have any problems as a student pilot with the helicopter doing something unexpected.
I did not use Bill’s notch filter, as my helicopter did not require it.
1.) Assuming servo arms and links are set up properly.
-H_SV_MAN != 0
-Set servo center points and direction so all servo arms are level with the frame.
-Adjust links for zero degree pitch. Some people like to adjust servo travels to compensate unequal geometry (symmetrical servo layout such as SAB Goblin might not need this) but I don’t think this is critical.
-Set H_CYC_MAX as high as possible without servo whining.(varies)
-Set H_COL_MIN and H_COL_MAX for ±10~12 deg (varies)
-Check output direction (follows radio sticks, counter airframe movement)
You can download RC heli manuals for detailed instruction (Gaui, Align, SAB, etc)
2.) Move radio sticks one by one to make sure that every channel is responding and all servos are functioning (had a few times when one servo needed a reboot)
3.) I have few different procedures based on how much I trust my heli.
-Fresh built, trying something dangerous: CH8 passthrough for throttle, no RSC_RAMP, raise throttle stick slowly which means I spool up under negative pitch.
-Ground resonance: Spool up and lift off as quick as possible.
-Finalized: Full throttle, rely on RSC_RAMP and ESC Soft-start
Dual rotor heli type which is new in 3.5 has little yaw control near zero pitch. This may allow yaw error to build up.
I’m curious. Is this something arducopter already does or something you would like to see it do? I have never seen this behavior when I boot up the pixhawk.
@Leonardthall the way I have my version coded with the pixhawk unarmed, the I term and attitude controller(acro mode only) are reset so the user can see the swashplate response and also see the swashplate move in response to disturbances if they desire to move the aircraft to simulate it for setup purposes.
One additional note is Rob’s setup video for the head on helicopters. This is pretty much the Gold Standard in head setup for traditional helicopters, and should be in the wiki IMO. The servo test no longer works like it did in 3.3 though. It now just cycles the servos at one collective position. It used to cycle the cyclic at both MAX and MIN collective to check for binding and proper cyclic range at the collective extremes. That should be fixed but it has nothing to do with the attitude controller.
There is a setting, H_SV_TEST that you can set for the number of test cycles of the servos on boot of the Pixhawk. It is turned off by default. It runs the servos thru their full range to check to make sure they are working properly and not dead, or that there is no binding. Most pilots will just check for correlation in pre-flight like you would on a full-sized heli, the servo test checks the servos at their max range, and is a nice feature already in the software.
Bill, in your latest code, did you include the changes for the DDFP tail fix? I haven’t had time to check all your commits. I got that from Rob, and then subsquently broke the DDFP tail fix out separately since, IIRC, he had made some other changes to AP_MotorsHeli_Single.cpp. I committed the DDFP changes to my repository and built the binary since I am currently flying the modified code with the DDFP fix in two helis.
No sorry I have not merged your DDFP tail fix. I do have a 3.5 version that i have been pulling changes from my 3.4.6 version that I referenced above. I’m preparing it to take my compound heli code from 3.3.3 to 3.5.0.
I think it’s ok to have them separate but I know Rob gathered up many of mine in 3.4.6 and his own and moved them to 3.5. He might look to put yours in there as well. I’m not sure what his plans are though.
So you like to be able to move the aircraft around on the ground and see the swash react. But to make it clear you are holding the I term to zero so it doesn’t saturate. This is something we could do for all modes by default. You could then do this test at all times.
So at what point would you like to see direct pass through of the controls to the swash and when would you like to see stabilized control?
Oh, sorry I forgot to mention that. I arm in Stabilize.
It is the Tip Path Plane of the main rotor. The attitude controller does a couple things - it tries to level the helicopter at all times with no stick input (In Stabilize). It dials in whatever ATC hover roll trim you have set in the params, on the ground before takeoff. I’ve always thought that should not become active until after takeoff. Especially with my flybars, they try to tip to the side by whatever the ATC hover roll trim is set for, and the flybar is quite authoritative about it, requiring significant left roll input on the cyclic to counter it as collective comes up to light on the skids.
So during spoolup I watch the TPP and if the heli is not on a level surface I start correcting it immediately to keep the main rotor’s TPP perpendicular to the mainshaft until I’m ready to start feeding collective pitch for liftoff. As collective comes up to hover and the heli gets “light on the skids” I will already be “flying” the helicopter on the ground so I have 100% control of where it goes laterally on takeoff.
Note, I do NOT see this as a flaw in the software (except for the ATC hover roll trim being active on the ground). It is part of being a helicopter pilot, whether you fly RC or a full-sized manned one.
Yes, it does. But again, it gets back to being a helicopter pilot. I learned to fly full-size manned helicopters long before I flew RC. And when I started in RC I learned how to fly those with no gyro’s at all. So it’s a habit you get into, automatically correcting for rotor torque on liftoff. After I lift off I gently see if the yaw gyro “has it”, then I’ll relax it and let the gyro (or autopilot) take over on yaw control. Other pilots may have a different technique - mine comes from flying no-gyro heli’s.
Ok, so lets try to work through the leaky I term and error limiting in acro. I would really appreciate it if everybody could try to keep an open mind and look at the range of ways we can handle these issues.
So lets start with trying to clearly define the challenges heli faces that we need to address. I will give it a go and rely on everybody else to correct, refine and add to the list.
Rotor disk is often only loosely connected to the autopilot meaning there can be a significant angle difference between the autopilot and the rotor disk. This can present challenges on the ground from I term build up causing the rotor disk to tilt without moving the body until the disk hits the ground or the body tips over and the disk hits the ground.
The average heli is carefully calibrated to be able to spin the rotor up with zero servo input without risk of the rotor tipping over. If I am correct here this is a very important difference between heli’s and multi’s that we need to facilitate. This would lead me to think that any I term build up at all during this phase would be a bad thing. Attitude stabilization may also be undesirable but would need to be weighed against the risks of tip over after take off.
The heli pilot has a mechanical feedback to the swash that they like to use to check for correct operation before flight. In ACRO they expect the swash to behave like a rate only controller with zero I term build up, maybe zero PD input too. In Stabilize they expect the swash to behave like a attitude controller with feedforward and zero I term build up.
Any others?
So lets start defining the problems and then we can look at how the the current suggestions address these problems. After that we can look at some alternatives that may provide improved performance or better integration with the wider code base.
So being able to tilt the aircraft pitch up and down and roll left and right and being able to watch the swashplate oppose the tilt without the integrator modifying the swashplate is more of a feature used in setup but in an unarmed state its nice to have, dare I say, control in the case of the aircraft accidentally disarming in flight. So that is why I recommend leaving it that way. So you are saying in unarmed state the swashplate would respond like I described above regardless of mode? I don’t know about the non-manual modes (i.e. loiter, auto,…). I would say for Stabilize and Althold, the swashplate should oppose attitude and for acro, the swashplate should oppose rate. [quote=“Leonardthall, post:13, topic:18281”]
So at what point would you like to see direct pass through of the controls to the swash and when would you like to see stabilized control?
[/quote]
I think direct pass through for a flybarless heli should only be done in a special setup mode which I believe the heli page in mission planner offers that capability but I don’t know if it still works. I haven’t had to do a setup in a while.
@Leonardthall could I suggest that we split these into different discussions. It is my opinion that the leaky I is mainly being used to address air/ground transition issues. Where as the error limiting is mainly addressing out of control flight or situations where the target attitude greatly differs from the actual attitude. I think it was convenient that the error limiting in AC 3.3.3 handled the issue on the ground of the target attitude running away but I have handled this through use of resetting integrator and attitude error (acro only) while on ground and leaking integrator and attitude(acro only) during transition and low speed flight (using Rob’s original implementation).
These are separate issues and it will get convoluted in trying to follow each of these issues.
My initial goal is to try to define what those discussions should be then address them one at a time. At this stage I don’t want to discuss solutions (other than in passing) just problems. We can then break them down one at a time and see where it takes us.
4). The Heli should be always stabilizing because there is no danger to stabilizing on the ground when the rotors are not spinning and in the event of disarm in flight it may enable a safe landing.
I see the first part is nice because of the on ground feedback but I am not sure how often heli’s are disarmed in flight. Is there some sort of state that the aircraft should be stabilized and disarmed at the same time in normal or relatively normal operation?
I am not looking for a reason to change this behaviour. This was one of the easiest steps we made before the last release to make heli and multirotor more consistent.
I am asking this question purely to improve my understanding.