Print

Print


OK Zack,

I agree with the option 3: add a new attribute of type AttitudeQuaternion.
Concerning the question if to leave this information in PhysicalEntity, I am trying to figure out pros and cons.

See you on Thursday,

Alfredo

-----Messaggio originale-----
Da: SAC-PDG-SRFOM [mailto:[log in to unmask]] Per conto di Crues, Edwin Z. {Zack} (JSC-ER711)
Inviato: lunedì 31 ottobre 2016 23:16
A: [log in to unmask]
Oggetto: Re: Potential issue with center_of_mass attribute.

Hi Folks,

I went ahead and implemented option 3 in PhysicalEntity.  I’ve also finish a first draft on the Entities and Interfaces section of the document.  Both the FOM document and FOM modules have been checked in.

Zack
*******************************************************************
* Edwin Z. Crues, PhD.           | Phone:  281.483.2902           *
* Mail Code: ER7                 | Mobile: 832.341.9023           *
* 2101 NASA Parkway              | FAX:    281.244.6116           *
* NASA Johnson Space Center      | Email:  [log in to unmask] *
* Houston, Texas 77058, USA      |                                *
*******************************************************************

> On Oct 27, 2016, at 2:20 PM, Crues, Edwin Z. {Zack} (JSC-ER711) <[log in to unmask]> wrote:
> 
> Hi Folks,
> 
> I’ve been cleaning up the semantics of the PhysicalEntity and DynamicalEntity object classes.  I think we have an omission.  The semantics for the center_of_mass currently state:
> 
>> A 3-vector that specifies the position of the vehicle center of mass (the body frame origin) with respect to the origin of the vehicle's structural frame. The components of this vector are resolved onto the coordinate axes of the structural frame.
> 
> Well, the orientation between the structural frame and the body frame is not included in the FOM data anywhere.  Without that crucial piece of information, I don’t see how the center_of_mass attribute is ever of any use.  There are a couple of ways to address this.  One is to change the semantics to state that the components of the vector are expressed in the body axis; however, this is not the usual way it’s represented.  The second would be to state that for the purposes of the FOM, it is assumed that the structural frame and body frames are co-aligned.  While this is sometimes the case, it is often not the case.  In essence, this is the same as the first option.  A third option would be to add a new attribute called struct_body_orientation.  This would define the orientation of the body frame with respect to the structural frame.  It would be of type AttitudeQuaternion.  This should never change during the federation execution and can be assumed identity if not published.
> 
> This then begs the question: If we go with option 3, should the center_of_mass and this new struct_body_orientation be moved into the DynamicalEntity object class or is there still reason to maintain it in the PhysicalEntity object class.
> 
> I’m inclined to go with option 3 but leave them in the PhysicalEntity class.
> 
> Thoughts?
> 
> Zack
> *******************************************************************
> * Edwin Z. Crues, PhD.           | Phone:  281.483.2902           *
> * Mail Code: ER7                 | Mobile: 832.341.9023           *
> * 2101 NASA Parkway              | FAX:    281.244.6116           *
> * NASA Johnson Space Center      | Email:  [log in to unmask] *
> * Houston, Texas 77058, USA      |                                *
> *******************************************************************
> 


########################################################################

To unsubscribe from the SAC-PDG-SRFOM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-SRFOM&A=1

########################################################################

To unsubscribe from the SAC-PDG-SRFOM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-SRFOM&A=1