Hello everybody,
I have a Problem and would like to hear your suggestions how to solve it:
Lets say there are three Cars which have the physical properties Speed, Position, ID, and Name.
The IDL looks like this:
struct VehicleState_T
{
int ID //@KEY;
string Name;
long Speed;
long Position;
}
In the end I want to see three instances of the Topic VehicleState_T which contain the Data from all three Cars.
Car 1 with the name TOM has a central data processing so all data is available from one Datawriter. --> No problem
Car 2 with the name MAX has two seperate processes from which each one can deliver either the speed or the position data.
Car 3 with the name SAM has only a speed sensor so the value of the position should be invalid.
Now my Questions:
How can the seperate Datawriters of MAX contribute to the same instance of VehicleState with the Key = 2 without overwriting the content of the other sensor and without having additional listeners to buffer the values of the other sensor?
How can I publish a Topic with some elements still invalid without defining specific values which have to be interpreted by the datareaders as invalid?
I would be glad if you have some sample code or example for me.
I look forward to hearing from you!
Sönke
Hi Felsing,
I think optional members would fit very well your use case. If you define your type as follows:
struct VehicleState { int ID; //@Key string Name; long Speed; //@Optional long Position; //@Optional };Now, you can write samples for a VehicleState topic that don't set a value for Speed or Position, and the subscriber will see that those fields are not set.
If you generate C code, the VehicleState C struct will contain a pointer for Speed and another pointer for Position, so NULL means that the value is invalid/unknown. See the User's manual here for more info.
Also, I think Name should be part of the key, according to the description for your problem:
struct VehicleState { int ID; //@Key string Name; //@Key long Speed; //@Optional long Position; //@Optional };I hope this helps,
Alex
I suggested making Name part of the key because it identified the sensor, but I realized that's not the case. I think you could add another field to identify the sensor ID and make it part of the key.
Otherwise you can increase the history depth of the writer and the reader to keep more than just the last update for each instance. But I would recommend the sensor ID.
Make two separate topics, one with a key and speed, and the other with the key and position.
Otherwise, make an accessory topic that has only position, and have "MAX"s speed model send its speed to the position model, which forwards it as part of the VehicleState struct.
Not to be hard-headed, but, how could a position model operate if it had no knowledge of speed? You probably need speed to esimate position or vice versa. At the very least, you can filter or postprocess your data if you have both.
Now, I realize you're presenting a contrived example, and I imagine that in your real application, the two sets of data are not intrinsically interdependent in the way that your example is.
The bigger point is that, if it's possible to completely separate the two types of data -- Which I assume is true, since you can have two sources with no mutual knowledge of each other generateing the data -- then why are you imposing the restriction in your data model, that the two types of data necessarily belong in the same topic? Doing so mandates that only one source has to generate both. It also mandates that both sets of data are deliered atomically with one timestamp. Do you really want that? What if position updates at 1hz and speed updates at 60hz? Are you going to send stale positions 59 times out of 60? How will you keep track of the time relationship between the two samples, when only one has changed? Will you have to add a pair of 'time of validity' fields to your sample to keep track?
If the data is truly independent, then split the data into two topics which can be delivered independently, and assemble the two parts of the data together at the receiver. Your life will likely be less complicated. :)