What can I do with a CSI?

Thinking about the demo this morning and wondering what jobs can be done with our CSI…if a CSI is like an API for a component it seems like we can connect nearly any component together with our CSI if they are using the same message spec? Couple the CSI with transforms and it seems like we can connect components with differing message specs? In other words, if @eric.zwirner wanted swap his LMCP component implementation for a MAVLink one, and then run an end to end test with AMASE could he (assuming the MAVLink message spec was in Tangram Pro and there was a transform from the MAVLink position message to AirVehicleState)?

A “CSI” as we define it is for the purpose of having setters and getters and serialization and deserialization code for working with messages represented by the message standard. The following is some of the C++ code that was used in this morning’s demo. It uses generic CSI generated code generated for the LMCP message set to create an AirVehicleConfiguration message, populate it, serialize it into a buffer of bytes, and send that message over a network.

// To serialize messages, we need an LMCP CSI entity factory and serializer
afrl::cmasi::DerivedEntityFactory entityFactory;
tangram::serializers::LMCPSerializer lmcpSerializer(&entityFactory);

// Create and populate an AirVehicleConfiguration message, which tells
// OpenAMASE about our platform. If this message is successfully received
// and processed by OpenAMASE the "Tangram UAV" platform will appear on the
// right hand side of the screen.
fprintf(stderr, "Starting AirVehicleConfiguration\n");
afrl::cmasi::AirVehicleConfiguration avc;
avc.setID(600, false);
avc.setAffiliation("Tangram Flex", false);
avc.setLabel("Tangram UAV", false);
avc.setNominalSpeed(25.0, false);
avc.setNominalAltitude(800.0f, false);
avc.setNominalAltitudeType("MSL");
avc.setMinimumSpeed(18.044F, false);
avc.setMaximumSpeed(33.223f, false);
avc.setMinimumAltitude(0.0f, false);
avc.setMinAltitudeType("AGL", false);
avc.setMaximumAltitude(100000.0f, false);
avc.setMaxAltitudeType("MSL", false);
avc.addToAvailableLoiterTypes(afrl::cmasi::LoiterType::EnumItem::Circular, 
    false);
avc.addToAvailableLoiterTypes(
    afrl::cmasi::LoiterType::EnumItem::FigureEight, false);
avc.addToAvailableTurnTypes(afrl::cmasi::TurnType::EnumItem::TurnShort, 
    false);
avc.addToAvailableTurnTypes(afrl::cmasi::TurnType::EnumItem::FlyOver, 
    false);

// Serialize and send the AirVehicleConfiguration message
fprintf(stderr, "Serializing AirVehicleConfiguration\n");
std::vector<uint8_t> avcBytes;
if (!lmcpSerializer.serialize(avc, avcBytes)) {
    fprintf(stderr, "Failed to serialize message.\n");
    return 1;
}
fprintf(stderr, "Sending AirVehicleConfiguration (%lu bytes)\n", 
    avcBytes.size());
if (sendMessage(&avcBytes[0], avcBytes.size(), 
    "afrl.cmasi.AirVehicleConfiguration", fd) == -1) {
    fprintf(stderr, "ERROR SENDING AirVehicleConfiguration (%s)\n", 
        strerror(errno));
}
printf("Sent AirVehicleConfiguration message.\n");
1 Like

As we talk about other message standards, the message names and field names change. For instance, AirVehicleConfiguration is LMCP specific and NominalSpeed is a field specific to that message.

So for some other message spec, the names change but the fact that messages are made up of a bunch of primitive types (integers, floating-point numbers, strings, enumerations) strung together to make complete messages stays the same.

For compatibility between implementations of the same message set, this can either be at the API level (same settters, getters) or at the serialization level. For the latter, that’s how we flatten the message out before pushing it to the network. Our generic CSI version of LMCP is not intended to be API compatible with what comes out of LMCPGen (the LMCP reference implementation) but it is serialization compatible.

For a transform to work, Tangram Pro uses getters from the source CSI and setters from the destination CSI possibly manipulating the data in between when conversions are required.

if a CSI is like an API for a component it seems like we can connect nearly any component together with our CSI if they are using the same message spec

That is exactly the point. However, remember that messages represent terms in a system’s ontology, so two arbitrary components that utilize the “same” CSI still need to speak the same terms.

Couple the CSI with transforms and it seems like we can connect components with differing message specs?

Transforms relate terms in different ontologies together. So, with transforms, if your system speaks a term that Tangram Pro can translate into a term that my system can listen to, then yes, that’s exactly what transforms allow for.

In other words, if @eric.zwirner wanted swap his LMCP component implementation for a MAVLink one, and then run an end to end test with AMASE could he (assuming the MAVLink message spec was in Tangram Pro and there was a transform from the MAVLink position message to AirVehicleState)

This is true at least in the abstract. The specifics of this, however, get into the idea of components and systems engineering that are a bit outside the realm of transforms.

1 Like