Graphics.OrbitalSimIntegration - lordmundi/wikidoctest GitHub Wiki

Orbital Sim Integration

« Adding overlays (more advanced) | EDGE User’s Guide | DCOMM Notes »

On this page… (hide)

  1. 1. Description
  2. 2. Instructions
  3. 3. The details
    1. 3.1 Sim orbital-graphics body inputs
    2. 3.2 Graphics node setup
    3. 3.3 Post sim visualization using API files
    4. 3.4 Running with comm for live sim graphics
  4. 4. Things to remember

1.  Description

The TRICK simulation interface code contained in the EDGE model pack is split into two parts: generic interface code (code that is input data driven and doesn't need to be edited by the user) and non-generic code (i.e. ANTARES simulation specific code for things like chutes, plumes, etc.).

TRICK plot
TRICK Monte-Carlo Run

If you are integrating EDGE graphics into the ANTARES simulation, then you are in luck. Most of the work has been done for you since the sim interface code is tested against the ANTARES simulation. You can find the ANTARES integration instructions here (see note below).

frankie April 09, 2008, at 10:29 AM: NOTE: Now that the ANTARES integration is done, the ANTARES integration article doesn't make sense any more for people using ANTARES. This article really only applies for people setting up new orbital bodies in ANTARES, or if someone wants to see the recommended way of integration with ANTARES.

If you are integrating into a different simulation, but the simulation uses the JEOD package for orbital dynamics, then you are still in luck. The generic code section of the model pack is set up to take in inputs from the JEOD package and drive orbital bodies in EDGE.

2.  Instructions

  1. Integrate the directories and files from the EDGE model pack as per the ANTARES integration instructions, substituting directory names and paths where necessary. Placement of the model directories can be anywhere accessible by the S_define via TRICK_CFLAGS, and the path to those models can be set using the #defines at the top of the S_module file. Make sure the libs are in a "linkable" location via the TRICK_USER_LINK_LIBS variable.
  2. Remove ANTARES specific objects and routines from the S_module file, Graphics.sm.
  3. Make another model directory next to the "generic" and "antares" directory to hold code specific to your simulation (we may be interested in rolling this interface code back into the delivered model pack).
  4. Edit "generic/include/orbital_graphics.h" to add in orbital body enumerations for each of your orbital bodies. Adding on to this list rather than redefining it would be appreciated since it would allow future integrations to take place more easily.
  5. Using "Modified_data/graphics_orbital_cm.d" as a guide, create an orbital graphics input file for each orbital body that you want to drive (more details about this below).
  6. Using "Modified_data/graphics_cev_ascent.d" as a guide, set up an input file that includes the files for each graphics orbital body according to the run type.
  7. Using "Log_data/log_graphics_ascent.d" as a guide, set up a data recording file that includes the orbital bodies according to the run type.

3.  The details

3.1  Sim orbital-graphics body inputs

The bulk of the work is in defining the inputs to the orbital-graphics interface code for each orbital body. You can use the delivered "Modified_data/graphics_orbital_cm.d" as an example.

First, we must define the node names that the simulation will drive. You should use a seperate node for position and attitude. Typically, these nodes follow the naming convention "bla_SIM_POS" and "bla_SIM_ATT":

NOTE: One advantage to making the enumerations in orbital_graphics.h is that those enumerations can be used here to directly address the element in the array.

… in.pos_node_name    = "CEV_CM_SIM_POS";
 … in.att_node_name    = "CEV_CM_SIM_ATT";

Next, we define the "struct_to_gmf" offsets. This is basically a vector and rotation describing the difference between the structural frame of the orbital body in the sim, and the model frame used for that element in the graphics.

/* Sim structural frame to Graphics model frame difference data */
 … in.struct_to_gmf.location[0]    {in} = 1278.0, 0.0, 0.0;
 … in.struct_to_gmf.euler_angles[0] {d} = 180.0, 0.0, 0.0;
 … in.struct_to_gmf.euler_sequence      = Pitch_Yaw_Roll;

Various options are available, but you will probably want the defaults initially.

/* Options */
 … in.enable_calculations               = True;
 … in.init_from_euler_angles            = True;
 … in.euler_seq_for_output              = Pitch_Yaw_Roll;
 … in.drive_element_in_scene            = True;
 … in.drive_with_eci_output             = False;
 … in.drive_att_with_rot_matrix         = True;

The last section is where you define pointers to your input structures. These variables use pointers so that they can be set from the input file and so that they can be changed during run-time (think Earth-Moon relative transition). Since you are using the JEOD package, this should be as easy changing the orbital body name to the one used in the S_define, and pointing to the appropriate RNP matrix.

/* Input */
 in.name                        = "CEV_CM";
 in.cm_vector_ptr               = cev_cm_veh.body.core.mass.properties.cm;
 in.T_struct_inertial.trick_ptr = cev_cm_veh.body.core.orbit.rot.T_struct_inertial;
 in.T_struct_body.trick_ptr     = cev_cm_veh.body.core.orbit.rot.T_structure_body;
 in.inertial_pos_ptr            = cev_cm_veh.body.core.orbit.trans.inertial_pos;
 in.rnp_matrix.trick_ptr        = env.bodies.body[Ephem_Earth].state.rnp.out.RNP;

That's it on the sim side. You should be able to rebuild your sim, run (with comm off), and record your data using the log data file you made to log all of your orbital bodies. Now we just need to set up the graphics side of things.

3.2  Graphics node setup

Now that the sim is ready to go and you have data waiting to be visualized, we need to prepare the graphics side of things to accept the data.

Basically, what we need to do is adjust the tree layout so that the nodes we want to drive are now parented to the _SIM_ATT and _SIM_POS nodes, and then parent the _SIM_POS node to EARTH_CENTER. For example, if we are going to set up the node "CaLV_SRB1" to be driven as an orbital body, we want to change the tree so that we have the following:

EARTH_CENTER → CaLV_SRB1_SIM_POS → CaLV_SRB1_SIM_ATT → CaLV_SRB1

Also, we will want to make sure that the default xyz and pyr of the model node to _SIM_ATT, _SIM_ATT to _SIM_POS, and _SIM_POS to EARTH_CENTER are all zero.

So how do we do this? Well, the best way is to put our customizations in "userdata/configs/user_models.cfg". In the "MODELS" block, for CaLV_SRB1 we would have the following:

# CaLV_SRB1 orbital setup
 node( CaLV_SRB1_SIM_POS ); xyz( 0, 0, 0 ); pyr( 0, 0, 0 ); parent( EARTH_CENTER );
 node( CaLV_SRB1_SIM_ATT ); xyz( 0, 0, 0 ); pyr( 0, 0, 0 ); parent( CaLV_SRB1_SIM_POS );
 node( CaLV_SRB1 ); xyz( 0, 0, 0 ); pyr( 0, 0, 0 ); parent( CaLV_SRB1_SIM_ATT );

After saving the file and running, you should see the _SIM_POS node tied to EARTH_CENTER and the _SIM_ATT node tied to _SIM_POS (as expected). BUT, the actual model node, CaLV_SRB1, you might find, is not parented to _SIM_ATT as expected. If so, this is most likely because of the "base state". The base state file is a state file that is loaded at initialization, and it is loaded after the tree is built up from the config files. So, if the nodes exist in the state file (such as CaLV_SRB1 probably did), then it's state will be overwritten. But, if the nodes do not exist in the state file (which is the case for the new nodes that we added), then the positions from the config file for those nodes will still be in tact.

The solution is to edit the nodes which are out of place using the node edit dialog, or the tree editor, and reparent the node to its intended parent. For CaLV_SRB1, we would reparent it to "CaLV_SRB1_SIM_ATT" and then change the xyz and pyr values to 0.0. Then, we save off a new state using "File→Save State". To make this state our new base state, we could either overwrite the delivered base state file (not the best method), or we could:

  1. save the corrected state under the userdata directory (userdata/states/USER_BASE would be good)

  2. modify "$USERDATA/user.cfg" to overwrite the BASE_STATE variable to point to the corrected state location:

    Point to the user-customized base state instead

    BASE_STATE ${USERDATA}/states/USER_BASE

Now, if we re-run the graphics, you should see the corrected state at init. Repeat this process for any new orbital bodies being driven in the graphics.

3.3  Post sim visualization using API files

Now that we have the graphics nodes in place that we need, we need to make a map between variables in the log file, and the node names / DOFs that they should drive. We do this through an API file.

For orbital bodies, you should be able to copy and paste lines from other orbital bodies in "sim_data/cev_graphics.api". For example, for the crew module nodes:

CEV_CM_SIM_POS graphics.orbital.element[0].out.ecef_to_gmf.location[0]  x   in   write  1.0
 CEV_CM_SIM_POS graphics.orbital.element[0].out.ecef_to_gmf.location[1]  y   in   write  1.0
 CEV_CM_SIM_POS graphics.orbital.element[0].out.ecef_to_gmf.location[2]  z   in   write  1.0
 CEV_CM_SIM_ATT graphics.orbital.element[0].out.ecef_to_gmf.euler_angles[0]  pitch  d   write  1.0
 CEV_CM_SIM_ATT graphics.orbital.element[0].out.ecef_to_gmf.euler_angles[1]  yaw    d   write  1.0
 CEV_CM_SIM_ATT graphics.orbital.element[0].out.ecef_to_gmf.euler_angles[2]  roll   d   write  1.0

This basically says (looking at the first line) 'Drive the x DOF of node "CEV_CM_SIM_POS" with the sim variable "graphics.orbital.element[0].out.ecef_to_gmf.location[0]" converted to inches'. For orbital bodies, this is exactly what we want so this should be duplicated for each one being driven. Again, use the delivered "sim_data/cev_graphics.api" file as a guide.


Sim data visualization interface

Once we have an API file made that has mappings for all of our nodes, we can use it by using the simdata plugin. It is selected by clicking "Options → Sim-Data Dlg". For information on how to use the Simdata plugin, see the Simdata plugin page.

3.4  Running with comm for live sim graphics

If you want to run with comm to EDGE so that graphics run realtime with the sim, do the following:

  1. Set the "DOUG_HOME" environment variable to the DOUG dir and source the environment:

    setenv DOUG_HOME <path_to_doug_directory> cd $DOUG_HOME source edge_env # (or .doug_cshrc for older versions < 2.2)

  2. Add the following to your input file:

    graphics.data.comm.active = True;

4.  Things to remember

  • When driving your new orbital bodies from the sim, make sure the cameras you are using are tied to the _SIM_POS node of the concerned body. This way, you can easily watch the sim motion, including rotational motion (if you use the model node or the _SIM_ATT node, the camera will move with the rotation, and you won't see it). The best way may be to add a new camera if one is not available and parent it to the _SIM_POS node of the object you want to track with that camera. Use "CM_Cam" as an example.

  • If you are driving your sim with live comm, you will probably also want to make sure that your sim is running with realtime turned on. This way motion looks reasonable, but more importantly, you won't flood the comm server with network messages.

« Adding overlays (more advanced) | EDGE User’s Guide | DCOMM Notes »