paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Paparazzi bus MQ wrapper


From: Felix Ruess
Subject: Re: [Paparazzi-devel] Paparazzi bus MQ wrapper
Date: Wed, 28 Jan 2015 18:58:59 +0100

Hi,

Felix, at the moment it's a string like ivy. It's possible to work with the message definition at the bus level, 
but if I understand this correctly, you'd get binary dependency and requirements to recompile the bus if a 
message definition changes (switching branches?). So it's mostly about having alternatives for changing the
underlying transport mechanism and interfacing with other systems.

Of course the pprzbus should not need to be recompiled to get updated message definitions, this has to done at runtime (like giving it the message specifications), otherwise it doesn't make sense.
Also implementations like ivy wouldn't need to care about that.
 
The reason for adding the sender parameter is how I saw that the regex's were used in general. Usually there's
no filter, so the app doesn't care about the sender, but in some regex's you get a "1" for the ac_id or a 
"ground" at the start. The regex is pretty difficult to parse and make sense of, so I made this an explicit
function of the API instead.

Regarding adding the sender:
I thin I would prefer it if you "simply" subscribe to a topic and not additionally filter on the sender.
In most middlewares using pub/sub you also don't have that.
Instead you usually encode the "sender" in the topic name by e.g. namspacing it...
 
Something like this is further away from Ivy and requires more work, but would better map to other middlewares (I'm also thinking about ROS here).

I imagine that an API call for bindings on the bus would then eventually look like this, without regex's:

bind_id PprzBusBind( MsgCallback callback, const char *msg_name, const char *sender );

So basically I was thinking if we shouldn't try to do something more like

Subscriber * pprz_bus_subscribe(const char *topic, MsgCallback callback);
or maybe
Subscriber * pprz_bus_subscribe(const char *topic, MsgType type, MsgCallback callback);


An option is probably also needed to split data arguments or not, because telemetry messages split the 
data arguments into an arg list before returning, whereas the gcs and server just return the msg_name+data
as one single line.

The need to distinguish between these cases is what I would like to avoid...
but would probably be a lot of work to map the purely string based Ivy approach to a message based one.

What would be nice if in the end we could "just" subscribe to topics (e.g. via redis) and get a full message back.
Meaning the client doesn't need to know messages.xml and parse that again, but can get that info either separately once from redis or get the message as a JSON object (including fields).

Also connecting ROS and mavlink to it would be great...

So basically I'm wondering how far we should go here, IMHO the benefit of just mapping the Ivy approach to e.g. redis is a bit limited...

Cheers, Felix

reply via email to

[Prev in Thread] Current Thread [Next in Thread]