Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Combine aerodynamic coordinate systems #279

Closed
NikolaiVChr opened this issue Apr 18, 2020 · 17 comments
Closed

Combine aerodynamic coordinate systems #279

NikolaiVChr opened this issue Apr 18, 2020 · 17 comments
Labels
Feature request

Comments

@NikolaiVChr
Copy link

The reference say: Systems may NOT be combined, or a load error will occur.

Feature request:
Is it technically hard to make jsbsim able to combine them?

I have several times been in the position of getting aero data for an aircraft from different sources that do not use same Coordinate system.
Its kind of messy to use trigonometry all the time to convert for example LIFT and DRAG into X, Z.

For example, it would be nice to be able to:
Axial-Normal coordinate system plus LIFT, DRAG
and
Body coordinate system plus LIFT, DRAG

Aren't they all converted into body system anyway internally?

Thanks for making JSBSim, awesome program. :)
@bcoconni
Copy link
Member

bcoconni commented Apr 19, 2020 •
edited
Loading

Is it technically hard to make jsbsim able to combine them?

Programming-wise, everything is possible, the frame transformation would have to be managed at the force component level rather than at the vector level. However from a user point of view, I am not sure it's a good idea since you would add up forces which are not orthogonal meaning that a force specified in the Axial Normal frame could modify forces you've specified in the Lift Drag frame. The result would be very difficult to follow and therefore to debug.

Aren't they all converted into body system anyway internally?

Indeed.

I would like to gather opinions from model designers on that topic before proceeding because, once again, I have a "bad feeling" about this.

@seanmcleod, @agodemar, @Zaretto, @legoboyvdlp, @jonsberndt, @Mike402, @Octal450, @dany93, @andgi
Any opinion about this ?

@ghost
Copy link

ghost commented Apr 19, 2020

Hi, thank you for the request,

I think, if possible, it would make sense to simply add up the forces resulting from specified normal+axial and lift+drag.

Personally, I have never had to use normal+axial yet but I can imagine a situation where different data on your aircraft are in different systems, so for one component you would end up working with one system and for another with the other -- and if JSBSim already does the conversion under the hood, adding up the forces without user having to convert them would make easier and safer.

Kind regards,
Mike

@seanmcleod
Copy link
Member

@bcoconni I was actually typing up a comment mentioning the possibility for confusion when creating xml functions etc. making use of values from multiple co-ordinate reference frames.

Currently you can use different coordinate reference frames for forces versus moments, but allowing the mixing of multiple frames within one set (forces or moments) has a large potential for confusion as you mentioned difficult to debug without having to add a bunch of extra code to for example confirm that all input parameters to a function come from the same reference frame etc.

@NikolaiVChr
Copy link
Author

Its already confusing to have a tons of trigonometry conversions between coordinate system. This would be less confusing. Much more clean.

I would like to add that this confusion you talk about, is also only when you mix the coordinate systems, which most people wont do anyway, so it will be no change for them.

You can maybe even put in a flag, that has to be set to be able to mix them.

@Octal450
Copy link

I agree.
Adding it is a good idea in my view, I'll give a little example.

I have in the MD-11 some data, but not all. I have CLalpha CDalpha and a few more like such, right? But lets say then I find more data for the things I don't have, and its presented in normal/axial instead of lift/drag. I don't see a reason to convert the entire data instead of just adding it to normal/axial axis' and have JSBsim do the conversion.

So as for difficult to debug, it really depends on the implementation. If you have lift vs alpha, and drag vs alpha, and then you also have normal vs alpha, and axial vs alpha - then yes that gets complicated to debug - but why would that happen? Combining multiple tables into one? In that case its better to just convert that data and use one coordinate system for those 2 alphas..

But having lift vs alpha, drag vs alpha... and then lets say normal vs flaps, and axial vs flaps... then its not difficult to debug at all. Or even normla/axial vs a table of flap deg and alpha...

Kind Regards,
Josh

@Zaretto
Copy link
Contributor

Zaretto commented Apr 20, 2020

I think this sort of conversion is better performed offline rather than at run time

Doing this offline is a one time task rather than being performed every frame and it makes the model easier to follow.

Maybe a sensible solution is to provide some tools to allow this to be done offline to ease the process.

My view is that it would be a bad idea to allow this to be done at runtime.

@seanmcleod
Copy link
Member

In terms of being difficult to debug I meant something along these lines. In other words individual forces can be specified in any of the 3 axes we support. Then somewhere else the user wants to make use of the forces in combination, and it's thousands of lines away (just recently been looking at @Zaretto's F-15 - https://github.com/FGMEMBERS/F-15/blob/master/f15a.xml) and the user forgets that the individual forces they want to use come from different sets of axes, and wonders why the resultant combo force isn't what they expected.

More so if multiple people work on the model over long periods of time.

<force1 axis='wind' />
<force2 axis='stability' />
<force3 axis='body' />

<function name='combo' axis='wind'>
   <product>
      <force1>
      <force2>
      <force3>
   </product>
</function>

@seanmcleod
Copy link
Member

seanmcleod commented Apr 20, 2020 •
edited
Loading

Maybe a sensible solution is to provide some tools to allow this to be done offline to ease the process.

Good idea.

@Zaretto given the number of reference sources you mentioned using for your F-15 did you just get lucky and all of them used the same set of axes, or did you 'manually' do lots of conversions into a common set of axes?

@alanjt
Copy link

alanjt commented Apr 20, 2020

I am with Zaretto on this.
My WIP (TSR2) aero data all came from one source (BAC Warton archives), but despite that some data was presented in Body axes, and other in Stability axes. The reference point (commonly refered to as c.g.) also varied between the the various reports. I guess it depended on who asked for the data.
So I transformed everything into aft cg, body axes. Except that is Lift and Drag, which are more commonly represented in stabilty axes. Body axes were chosen for the lateral equations, because at the time when I wrote the FDM, this was the only opting provide by JSBSim.
As the data was digitised from graphs, it was necessary to do a lot of spreadsheet work, so the transformation of axes and CG was quite trivial.
We already have an example of bad practice where users are allowed to adjust the aero ref point at run time. They should really be adjusting the CM vs incidence table.
Alan

@Zaretto
Copy link
Contributor

Zaretto commented Apr 20, 2020

@seanmcleod most of the aerodata came from the same report - and I think the rest is mainly now based on directly or derived from the VSPAERO model that I built in 2016

I'm using stability axes even though the report is probably using body axes because otherwise the sustained turn performance is very far from what it should be.

Also please don't use the FGM repository for my models - it's a very long way out of date - either https://github.com/Zaretto/fg-aircraft/ or FGAddon for both the F-14 and F-15. The develop branch on github is the most recent.

@bcoconni
Copy link
Member

@Zaretto I like your idea of providing an external tool 👍 I am trying to revive JSBSimCommander - as a long term goal - but the code is more than 12 years old and it needs to be modified to compile with the modern version of wxWidgets (version >= 3.0).

Contributions are welcome !

@seanmcleod
Copy link
Member

@bcoconni I'm interested in seeing JSBSimCommander revived. In particular to be able to quickly glance at aerodynamic data in a graph form and to view and manipulate the FCS. However I'm not sure how much time I'll have available 😢

@seanmcleod seanmcleod mentioned this issue May 1, 2020
Closed
@bcoconni
Copy link
Member

This issue is stalled for a few months and I think some kind of an agreement has been reached that mixing coordinate systems is not a good idea.

This issue is now closed.

@alanjt
Copy link

alanjt commented Oct 17, 2021 via email

@bcoconni
Copy link
Member

@alanjt Forces and moments are independent vectors so it is quite trivial to manage the situation where they are supplied in different coordinates frames.

However the current feature request is asking for the ability to provide each component of the force vector in a different frame. That's quite a different story ! The components would not be independent, especially when the frames in question have a relative movement between themselves (the wind frame is not fixed in the body or stability frames; neither is the stability frame fixed in the body frame).

Even if we could manage to provide a means to supply vector components in different moving frames, the mathematical problem of defining properly each aerodynamic force component in different moving frames is quite challenging and, I may be wrong, but I'm afraid this feature would result in a number of broken/ill defined/faulty models that would be hard to debug.

@alanjt
Copy link

alanjt commented Oct 22, 2021 via email

@bcoconni
Copy link
Member

@alanjt No apologies needed. You are perfectly entitled to challenge the discussion 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@seanmcleod @alanjt @Zaretto @NikolaiVChr @bcoconni @Octal450