Re: [Jsbsim-devel] Matlab-JSBSim Interface

[D W. <hdw...@gm...>]

Philippose Rajan wrote:
> First...Wysong...well...my intention right from the
> beginning..was to try and come up with a
> "Co-simulation" interface between JSBSim and Simulink,
> because my base intention (really long term :-)!) is
> to work on a UAV based on a model helicopter. For
> this, I wanted to run the control systems design on
> Simulink and use JSBSim for the Flight dynamics part
> of it.

Yep, I realized it was Sam that was after the strip charting instead of
you.  You two look so much alike that I got confused.  ;-)

> "Simpack".... This is what I am aiming at reaching.

Thanks for the info.  Haven't heard of it before and will take a look.

> 1. You cannot perfectly synchronise the start of
> the simulink simulation and the JSBSim
> Simulation...JSBSim needs some time before it starts
> putting out values. And since you need to drive the
> JSBSim simulation via Simulink...Simulink will
> start-up faster.

Understood, but do you actually *need* a hard sync?  I'm trying to think
of a model that would require it... but can't come up with one at the
moment.  Perhaps I'm misunderstanding the issue and you're simply
worried about gracefully bringing both sides up and getting the socket
properly initialized?

> 2. 120Hz is 0.0083333333.....seconds...you will end
> up with a drift due to differences in sample steps
> unless you can specify the time step upto exactly the
> sae number of decimal points as in JSBSim.

Keep in mind that a 120 Hz sim clock is "soft" so you'll really be
running at closer to 100 Hz relative to a wall clock (limitation of both
native Linux and Windoze).  For this reason we're already in a
non-real-time mode, so your sim clock is *the* clock.  You're free to
run the core (JSBSim) and the models (Simulink) at whatever sim rate
(dt) you want... and if it takes 5 minutes of wall clock time to run one
step of sim time, so be it.

>    3. You cant really run a normal simulink model in
> real-time...unless you use Realtime workshop to
> generate code and compile
> it....etc...etc....basically...if you choose a fixed
> time step simulation mode and press "play"...Simulink
> does not simulate in real-time. On the other
> hand...JSBSim I assume simulates in real time when the
> "--realtime" switch is provided. So you will end up
> with a confused simulation system :-)!

If you put your Simulink model inside a discrete, triggered subsystem
you get to decide when it gets kicked off.  So, your Simulink model sits
and waits on a blocked socket and only executes when data arrives from
JSBSim.  The sim dt is set by you... and it'll be free/clear of any wall
clock constraints.

>    Becuase of all this, and because JSBSim is more
> felxible than Simulink, I thought we could probably
> drive the JSBSim clock from Simulink by sending the
> current simulation time along with the data sent out
> from Simulink...and then JSBSim simulates the current
> time step...and gives back the results.

... heh heh.  I've been hit by that train before.  ;-)  I'd give the
triggered subsystem a try and leave the timing to JSBSim.

>    As for a union...thats something I hadnt thought of
> :-) So...shall try to look into that option
> too...thanks Wysong :-)! Only problem...in the windows
> socket "recv" command...the incoming data comes in as
> a character array pointer...and in the "send"
> command...the outgoing data is also a "char
> *"...doesnt that mean that you are restricted to send
> on character arrays? As in...for the network
> layer...there is only one datatype...the "char".

I'll send you an example.  It works like a charm.

> Driving went quite well today :-)! Just...the
> Germans seem to be a little more agressive than me :-)
> Places where I would feel most comfortable at around
> 65km/h..I had to hold the steering wheel tight and go
> to over 85 :-)!!

Just honk at 'em!  ;-)

D