A proposal for unifying type mappings, channels and outputs

[ivanperez-keera]

Currently, users need to provide additional variable DBs, which are custom to specific targets (i.e., cFS, ROS). The format is very cryptic, so users are having a hard time understanding the format they need to use for each backend.

I have an idea to unify all of that. See below the format I'm proposing. Let me know if you have any thoughts:

{ "inputs":                                                                      
    [ { "name": "variable1"                                                      
      , "type": "double"                                                         
      , "connections":                                                           
         [ { "scope": "cfs"                                                      
           , "topic": "MY_APP_MSG_ID"                                            
           }                                                                     
         , { "scope": "ros/message"                                                      
           , "topic": "/some_app/topic"                                          
           }                                                                     
         ]                                                                       
      }                                                                          
    ]                                                                            
, "topics":                                                                      
    [ { "scope": "cfs"                                                           
      , "topic": "MY_APP_MSG_ID"                                                 
      , "type":  "my_app_msg_t"                                                  
      }                                                                          
    , { "scope": "ros/message"                                                           
      , "topic": "/some_app/topic"                                               
      , "type":  "std_msgs::msg::Float64"                                        
      }                                                                          
    ]                                                                            
, "type_mappings":                                                               
    [ { "scope1": "cfs"                                                          
      , "type1":  "my_app_msg_t"                                                 
      , "field1": "data_field"                                                   
      , "scope2": "C"                                                            
      , "type2":  "double"                                                       
      }                                                                          
    , { "scope1": "ros/message"                                                   
      , "type1":  "std_msgs::msg::Float64"                                       
      , "field1": "data"                                                         
      , "scope2": "C"                                                            
      , "type2":  "double"                                                       
      }        
    , { "scope1": "ros/variable"                                                   
      , "type1":  "std::int64_t"                                       
      , "field1": "data"                                                         
      , "scope2": "C"                                                            
      , "type2":  "int64_t"                                                       
      }                                                                      
    ]                                                                            
, "outputs":                                                                     
    [ { "name": "output1"                                                        
      , "type": "double"                                                         
      }                                                                          
    , { "name": "output2"                                                         
      }                                                                          
    ]                                                                            
}

[ivanperez-keera]

This is not a complete example but, rather, several elements that could be in what is currently being termed a variable "DB".

Ideally, users should be able to provide multiple of these, and they'd all be put together. That way, you can have one for cFS, one for ROS, and some that Ogma already knows about, and list them all in the CLI.

[ivanperez-keera]

Some could also be implicit (Ogma would know them and add them without asking).

[ivanperez-keera]

For example, the int64_t type mapping is just there but unrelated to the application. It's just a way to help Ogma map types across.

[ivanperez-keera]

Some elements would also be optional. For example, there would be no topics in F'.

I've also been thinking about adding scopes for variables, topics for outputs (optional), and dependencies for types, just for ease of use.

[xander-will]

Assuming this is meant to be a move towards JSON variable DB mappings, us at VCU are absolutely in favor of this, since we'll be auto-generating these in Python, and the two work extremely neatly together. Per the format for the mappings: the more I think about bundling all of the scopes and their fields, it does seem like the easiest to grok from a readability point of view (the big benefit to moving to this from the previous one is, like you said, the old format was cryptic, and the lack of field names was a big factor in that). On the other hand, my inclination from a programmatic parsing point of view (mainly for writing this config file in our case), would be something more like the following?:

"type_mappings":                                                               
    [ { "cfs": 
          { "type":  "my_app_msg_t"                                                 
          , "field": "data_field"
          }
      , "C":
          { "type":  "double" 
          }                                                
      }                                                                          
    , { "ros/message": 
          { "type":  "std_msgs::msg::Float64"                                                 
          , "field": "data"
          }
      , "C":
          { "type":  "double" 
          }                                                
      }
    , { "ros/variable": 
          { "type":  "std::int64_t"                                                 
          , "field": "data"
          }
      , "C":
          { "type":  "int64_t" 
          }                                                
      }                                                                    
    ] 

There's a compactness lost by formatting it this way, and the "scope" fields aren't as apparent, but for us generating or parsing these files it's cleaner imo to avoid having to track some sort of "index" number in the field names, especially if this idea were to be extended out to more than two scopes at once (in the hypothetical scenario that multiple language backends come around eventually and we want to have mappings from a ROS variable to both a C and Python equivalent or something similar). Still, for either format the parsing wouldn't be a heavy lift. Thanks for adding this bit of QoL for us end users, and looking forward to trying some of the new features soon!

[ivanperez-keera]

Thanks a lot, @xander-will . What you propose is interesting, and more structured that a plain list of type mappings.

I'll think about it.

It's my pleasure, and thank you for dropping by to offer input. Sometimes it may take me a bit more than I would like to be able to act on it, but it's always very useful to hear your pain points, and your perspective. Your idea of having output values in handlers, which I originally didn't think was going to be so important, has turned out to open many possibilities that will impact not just monitoring and assurance for aerospace, but how we generally write (aero-)space applications.