Closed tubeme closed 6 years ago
Can you summarize how you'd like it to work?
Two ways simple and deeper:
Simple way.
Make Flaps fully extend in Manual modes and Guided modes and Mission. Make the Flaps extend slowly in all modes like it is in Position mode now. Provide a parameter to control the timing of the flaps extension. IE 2 seconds for the movement from current position to the set point.
Deeper way.
Give us a scaling parameter for manual modes. We decide how much the FLAPS will extend in Manual modes. Give us a different scaling parameter for guided modes Alt/Pos and Mission. We decide how much the FLAPS will extend in Guided and Auto modes. Give us parameter to control the timing for Manual Modes, so we could decide how fast or slow the FLAPS will perform in Manual modes. Give us another parameter to control the timing for Guided and Auto modes so we could decide how fast or slow the FLAPS will perform in Guided and Auto modes.
Thanks for the detailed response.
For manual mode do you need flaps to be binary (ON/OFF), have multiple positions, or be continuous (RC knob)?
Why is it important to control the timing? Would a longer default be sufficient? Maybe the deploy speed should actually be a function of airspeed?
Why do the flaps need to behave differently in alt/pos, mission, etc?
I'm trying to understand fundamentally how they need to work. If possible I'd like to avoid adding many tuning parameters when those same values can be derived.
No binary FLAPS. It is always a good idea to have control over the extension. If I use 3Pos switch then I have two positions for the flaps in strong wind we use middle extension in good conditions we need full extension. If I use rotary knob then that is OK as well we have control all the way. Different people different styles.
The timing is needed because there are different types of aircraft and different flaps. We need fast (but no sudden) flaps for parachuting to the ground (flaps that extend almost perpendicular to the wing) We might need 0.5 - 1 sec extension. While for other aircraft (larger one that land on a tarmak) we might need something like 2-4 sec. So PX4 is kind of universal and used with different machines so we need more control over the flaps that is appropriate for the machine. If we go in the direction of deployment corelated to the airspeed, we will create a new mess we will have to tune it, test it etc etc. and at the end this corelation will be different for the different frames again we will need some other sort of parameter tuning to make it work properly. Because Flaps are set and forget once per setup thing it is better to be as simple as possible. So couple of parameters will do a perfect job. The guy who makes the machine will tune it to their frame and have it working all the time "not dependent on faulty airspeed sensor" for example.
Why do we need scaling. The thing with flaps is that they are some problems when you tune them. Usually the 0 point has to be perfectly aligned with the wing. If the mechanic did not implement adjustable rods, everything should be properly tuned in the RC. So you manually tune the 0 point such that the flap is aligned with the wing. The same holds for the fully extended position. Very often the full move of the servo is too much flap. So we have to reduce the movement ie we do trimming in the RC. Instead of doing it in the RC it is good idea to make it in the PX4, because otherwise the FLAP becomes dependent on the RC. Which is not good idea if we are RC'less flying. And also because it will not be possible to automate it in the Mission etc.
Why do we need different sets for Manual and Pos/Alt + Mission. There are only two sets. One for the manual modes one for the guided and auto modes.
Sometimes we might want to be more aggresive with the flaps for some reason. This could be the case in Manual. When you are in manual it is supposed that you know what you are doing so you might need more aggresive timing and extention for the flaps. While in the guided modes +auto modes you have to be more gentle with the flaps because there is certain autonomy of the machine so we cannot go to the extremes. This means that this way we will have two whole sets of flap parameters. Triming + timing for the manual (more aggresive if we need it) and Triming + timing for the guided and auto modes (more gentle if we need it).
Of course there could be just one set of parameters triming + timing but then dependent on our needs we might loose the option to differentiate the flaps in the two modes.
I know that it is good idea to avoid parameters in general. But very often it proves that adding two or four parameters is much better, much simpler and more reliable than the derived option. Like I mentioned before what will happen if we are in airspeed'less mode?? How do we extend the flaps? Or if we have a faulty reading of the airspeed?
Lastly Flaps are set and forget thing. You tune it once you forget about it until the plane is dead. But we need some tools to properly tune it. Even if 90% of the people will not use this tuning in both modes, there might be some 10% that will need it. And it is better to have it and not use it instead of needing to set it up but not have the option. That makes the great product great, not the 90% satisfaction. But this extra 10% of detail will bring a lot of happy smiles.
It doesn't mean it has to be a dumb function of airspeed. Flaps increase the lift coefficient (and drag) and lower the minimum airspeed. For example this could be yet another tool the FW position controller (TECS) has at its disposal (with or without an airspeed sensor), but the utility decreases if you force it into an artificially simple model. You could then have a lower minimum airspeed configured (FW_AIRSPD_MIN) than you could achieve without flaps, but the controller would deploy them incrementally only as needed.
If the parachute/airbrake scenario is important we should do it explicitly instead of trying to deceive the autopilot by having it deploy flaps quickly. Tell it what you want to do, don't try to trick it into achieving what you want.
With scale factors we're just replicating functionality that's already in the mixer. If it's too hard to do it in the mixer then we should focus on making that easier instead of adding even more configuration on top. If you want to adjust the center of a servo there are already per PWM parameters for offsets.
The main thing I'm wondering for manual is you wanted to manually control the flaps (RC PWM -> FLAPS) or simply ask for position 1, 2, etc. We could simply slew it, but I'm now wondering if we should be doing anything at all. In many (most?) transmitters you can set a delay. If you really want manual mode perhaps the autopilot should stay out of it entirely.
For now I'm happy to make the hard coded flap deployment time a parameter, I just want to pause and consider both short term needs and potential longer term solutions.
@dagar I agree with your arguments. Will think about the use case scenarios and write them down. Then we could move on.
I agree with the scaling and the Mixer. But last time when I tuned the throttle of an IC engine servo I spent 1 hour tuning it with the current mixer, and spent 20 minutes for the flaps.
And I don't know a person here that understands what is going on in the mixer and can edit it. So you are correct probably we need a decent Mixer editor... I remember there was a PR for this. Even @DonLakeFlyer created a Tab in the Parameters view. The Mixer indeed is very powerful, but with cumbersome control.
PWM parameters for offsets are not usable. To enable this by channel PWM parameters I have to create a custom script otherwise they apply to the whole bus. I have a trim per channel from the Parameters view, but this is not what we need because we need to control the throws as well to tune the flaps. The same holds for the throttle servo if we use IC engine. Probably a decent Mixer editor could be great to solve all this problems.
Hey, this issue has been closed because the label status/STALE
is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a temporary error. The following address(es) deferred:
ricardo@hotchipsandsalsa.com Domain evercl.com has exceeded the max emails per hour (239/200 (119%)) allowed. Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o5.sgmail.github.com ([192.254.113.10]:60419)
by apollo.graphium.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.89_1)
(envelope-from bounces+848413-ff8b-rr=evercl.com@sgmail.github.com)
id 1eoU71-0007pX-Lm
for rr@evercl.com; Wed, 21 Feb 2018 08:07:20 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com;
h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=1IRgE/AqOung0I1JJyzDk80wb9I=; b=jAdaQerBZwIHaBcP
3FtbWMVy7O744qj5iOeuXdIytHUHXyHnWAmYZ+32fo7epkWZLwKgwLnw1R0QGteo
K0xuVxkVBhN1+b08FT2tD96fvaax2KFq19Q5d06cHTGWXQbYEtLMJpAV2MXFjArY
k1f44L0YqukQvren/pxP1lJxNwU=
Received: by filter0306p1iad2.sendgrid.net with SMTP id filter0306p1iad2-696-5A8D6E59-2A
2018-02-21 13:04:26.070197435 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17])
by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id _cqEPGVpTyuo_rvP_AIA7Q
for rr@evercl.com; Wed, 21 Feb 2018 13:04:25.881 +0000 (UTC)
Date: Wed, 21 Feb 2018 13:04:26 +0000 (UTC)
From: PX4 Build Bot notifications@github.com
Reply-To: PX4/Firmware reply@reply.github.com
To: PX4/Firmware Firmware@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Message-ID: PX4/Firmware/issue/7548/issue_event/1484605890@github.com
In-Reply-To: PX4/Firmware/issues/7548@github.com
References: PX4/Firmware/issues/7548@github.com
Subject: Re: [PX4/Firmware] PX4 1.6.3: FLAPS performance follow up. (#7548)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5a8d6e57b08f2_53a83fa09673af34148824";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: PX4BuildBot
X-GitHub-Recipient: evercltech
X-GitHub-Reason: subscribed
List-ID: PX4/Firmware
----==_mimepart_5a8d6e57b08f2_53a83fa09673af34148824 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit
Closed #7548.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/PX4/Firmware/issues/7548#event-1484605890 ----==_mimepart_5a8d6e57b08f2_53a83fa09673af34148824 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Closed #7548.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
----==_mimepart_5a8d6e57b08f2_53a83fa09673af34148824--
Follow up from #4438
In 1.6.3 the FLAPS are operational but there are still some concerns about the flaps behavior.
In manual modes the flaps extends full way.
In guided modes ie. Altitude and Position the flaps extend half way.
Also there is very nice touch in Pos/Alt modes that the flaps does not extend full speed but rather we see slow movement from point to point. This is very nice because fully extending flaps right away is not good idea in the airplanes. So this could be applied to the manual modes as well.
There might be a parameter to allow us to choose how long it will take to extend the flaps. 1,2,3 seconds etc.
I agree that it has logic to extend the Flaps a little less on the safe side for Position and Altitude modes but half way is too much. I could not find a way to make it fully extend in guided modes.