APM:Plane 3.7.0 released

Thanks Tridge! I know how hard you guys work on this stuff so don’t take my issue too negatively. APM:Plane just keeps getting better and better because of you guys so keep up the great work :slight_smile:

Thanks @tridge, I appreciate the fix very much.

How come theirs no twin-engine support instead of Y cable on the throttle i like to have it on its own Rc in channel

You can use a 2nd channel for your motor. For example, if you want channel 7 to be a 2nd motor output then set RC7_FUNCTION=70
See http://ardupilot.org/plane/docs/parameters.html#rc7-function-servo-out-function
This is a new feature in 3.7.0

sorry my bad i was reading the wiki and its not listed there in plane when i look in mission planer RC7_FUNCTION=70 was not there i just did an update mission planer guess what its there now

Just had a thought with the issue I’m still facing. I’m using very responsive multirotor type escs with BLHeli, dedicated gate drivers and hard breaking on my plane. It’s also a twin tractor prop with a good power to weight ratio.

Is it possible that the throttle response is too quick to accelerate and decelerate and the osscilations are caused by the throttle response demand loop being too sensitive. Is there a PID loop that can be tuned for the throttle output?

@Glen there are many throttle slew options. Check http://ardupilot.org/plane/docs/parameters.html for:
TKOFF_THR_SLEW - during takeoff
THR_SLEWRATE - during normal flight
LAND_THR_SLEW - during landing

@MagicRuB Slew is only about changing the rate of throttle change per second as I understand it. I’m thinking my problem might be caused by the AP requesting a 5% change for instance and the plane surging forwards too fast because the prop spins up / slows down very quickly. Is it not possible that the autopilot is getting more acceleration or deceleration than expected while trying to maintain a particular airspeed with throttle management?

reducing slew will reduce the feedback agility, effectively adding delay to the system. Slew is intended to protect the battery and motor from physical harm by over exerting and also to reduce roll by adding a high amount of torque to the system. Perhaps we’re talking about different things?

If you’re asking about modifying the control system to reduce demand, then you would want to take a look at all the TECS params, starting with TECS_CLMB_MAX

@MagicRuB Thanks for your response. Do you think it could be caused by the climb max being too high for the airframe?

I have reflashed and re-tuned numerous times both manually and with autotune as a basis as well. I’ve also swapped all of the hardware with the exception of the pixhawk and the ESCs to try and cure the issue. Do you mind having a look at one of my logs and seeing if there’s anything you can put it down to? It usually only occurs in cruise mode and it seems to depend what throttle position I have (or what demanded airspeed I have, since throttle nudge is on) If I change the throttle up and down enough I eventually can get a spot where the throttle and pitch respond as predicted:

7.5 minute mark: https://www.dropbox.com/s/4vs6tvkrr7h8gb1/8.BIN?dl=0

17.5 minute mark: https://www.dropbox.com/s/hw6y8csr3jmkib8/7.BIN?dl=0

It’s definitely TECS related as it presents as an oscillation on the pitch and the throttle (height control).

You may want to look at TECS_TIME_CONST too. That is the parameter that determines how quickly TECS tries to correct a airspeed or altitude error. If you are getting too rapid surges for your taste than increasing TECS_TIME_CONST will slow things down.

@Glen Thanks for posting the logs. However, do you mind posting your help questions on a new discuss server thread instead of on the 3.7.0 release announcement? It will get more visibility and I, or Tridge, or someone form the community can take a look at your logs to help diagnose your tuning issues.

In the code I can see that it supports RMP sensor. It appears that the RMP sensor outputs RPM as PWM. I was wondering what is the sensor which is being used to measure RPM. I am trying to build one using Hall effect sensor and arduino mini. If I can find a ready made one then I do not have to build one.

can’t get the RPM sensor to work… I set all the relays to -1, brd_pwm count to 0, still nothing rpm1=0 even if aileron out is connected to it…

Ok… I am past the end of my patience with the documentation…or whatever it’s called.

Does APM:Plane 3.7.0 exist?
If so, where the heck is it?
Is it called something else?
Is it a secret?
Has it been deprecated?
Is it vaporware?

Thanks for your responses in advance…

3.7.1 is now out - APM:Plane 3.7.1 released
Readily available through mission planner

Thanks MarkM,

So… As I am hoping I am not losing my mind… the name has been changed in Mission Planner to Ardu:Plane V3.7.1 and is no longer APM:Plane.

and, just to make more sense…

If I use an APM 2,7, with the current Mission Planner, download Ardu:Plane 3.7.1 firmware, when I go off looking for Q_ENABLE as per the directions to “unlock” all the wonderful features of Quadplane… it just doesn’t exist. (This was after spending a half hour looking for the “Advanced” selection. :slight_smile: )

Perhaps Quadplane wonders are already enabled?

Thanks again… I endeavor to be smarter than my gadgets.

@nicholsdrones Plane 3.7 doesn’t support APM 2.X hardware anymore. It hasn’t since Plane 3.4

Hello, which mode support SET_ATTITUDE_TARGET. messages???

Hi! Did you managed to find an RPM sensor that works? Or how did you configure your engine to measure RPM? I have an engine that comes with an ignition system that measures RPM and has an RPMs output. How can I get this RPM readings inside Pixhawk?