Implementing actuator dynamics

[Dobid]

Hello again, in the goal of having a more realistic simulation of my UAV, I would like to add the actuator dynamics (elevon and throttle) described by those 2 transfer functions :


I went through the FGFCS documentation and I couldn't find a way to implement it. Is there a way to implement such transfer functions in the FDM file of my aircraft ?
Thanks in advance !

[jonsberndt]

This might help:

https://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdf

[Dobid]

Awesome, thanks a lot !

[seanmcleod]

Yep, I was going to point you to the JSBSim Reference Manual which on page 46 starts describing the filter components. Looks like it's pretty much the same text included in Jon's Automatic Flight in JSBSim link above.

In addition to the filters also take a look at the actuator component.

jsbsim/src/models/flight_control/FGActuator.h

Lines 54 to 118 in 056bb71

	/** Encapsulates an Actuator component for the flight control system.
	The actuator can be modeled as a "perfect actuator", with the Output
	being set directly to the input. The actuator can be made more "real"
	by specifying any/all of the following additional effects that can be
	applied to the actuator. In order of application to the input signal,
	these are:
	- System lag (input lag, really)
	- Rate limiting
	- Deadband
	- Hysteresis (mechanical hysteresis)
	- Bias (mechanical bias)
	- Position limiting ("hard stops")
	There are also several malfunctions that can be applied to the actuator
	by setting a property to true or false (or 1 or 0).
	Rate limits can be specified either as a single number or property. If a
	single <rate_limit> is supplied (with no "sense" attribute) then the
	actuator is rate limited at +/- the specified rate limit. If the
	<rate_limit> element is supplied with a "sense" attribute of either
	"incr[easing]" or "decr[easing]" then the actuator is limited to the
	provided numeric or property value) exactly as provided.
	Lag filter's numerical integration assumes that the lag parameter is
	constant. So a continuously varying parameter via a property will introduce
	a non negligible error that will accumulate as the simulation progresses.
	Syntax:
	@code
	<actuator name="name">
	<input> {[-]property} </input>
	<lag> {property name | value} </lag>
	[<rate_limit> {property name | value} </rate_limit>]
	[<rate_limit sense="incr"> {property name | value} </rate_limit>
	<rate_limit sense="decr"> {property name | value} </rate_limit>]
	<bias> number </bias>
	<deadband_width> number </deadband_width>
	<hysteresis_width> number </hysteresis_width>
	[<clipto>
	<min> {property name | value} </min>
	<max> {property name | value} </max>
	</clipto>]
	[<output> {property} </output>]
	</actuator>
	@endcode
	Example:
	@code
	<actuator name="fcs/gimbal_pitch_position_radians">
	<input> fcs/gimbal_pitch_command </input>
	<lag> 60 </lag>
	<rate_limit> 0.085 </rate_limit> <!-- 0.085 radians/sec -->
	<bias> 0.002 </bias>
	<deadband_width> 0.002 </deadband_width>
	<hysteresis_width> 0.05 </hysteresis_width>
	<clipto> <!-- +/- 0.17 radians -->
	<min> -0.17 </min>
	<max> 0.17 </max>
	</clipto>
	</actuator>
	@endcode

So in combination with the filter component and the actuator component you should be able to match your example above.