Construct a ROS Data Source

[cfirth-nasa]

OnAIR should have an adapter to fit into ROS-based systems, mainly in the sense of being able to pull data in from ROS. I've been working on one for some TurtleBot demos, using only topics with a simple subscriber. This creates some blocking behavior that can probably get fixed with threading, which I can play around with. The major question is how OnAIR should (usually) expect to get data from ROS - I would make the argument that data input is going to come from topics, and individual plugins can call services and actions as needed.

Topics, services, and actions have specific ROS definitions that can be found on their wiki. For basic purposes, topics are like Redis channels, with other ROS systems publishing to them on a specified cadence. A subscriber runs a callback function every time a message is heard, and we can extract the data from that.

Interested to hear other folks thoughts - I'll set up a branch and start putting up the basic version I've been using.

[cfirth-nasa]

Basic functionality is pushed to the branch - OnAIR can receive messages published to a ROS topic. The topics, and what kind of message they contain (ROS topics each have a pre-specified message type, like strings, bools, or more complex data structures) are defined by the user in the config json.

The primary issue persists from above, and to my knowledge also affects the Redis adapter, the other subscriber based data source - how do we operate OnAIR in relation to the cadence of incoming data? Or, how do we choose when OnAIR loops? In the current ROS implementation, the system hangs waiting for a new message from any of the subscribed topics, then runs a full loop of OnAIR. It might be better to have more control over that choice.

This creates two problems: what do we do if we want to run OnAIR more frequently (or less frequently) than new data is published? And what do we do if the publishing source stops publishing data?

I'd suggest we implement two timeouts - one for a single loop (if a message is not received within X seconds, run OnAIR with the most recently received data), and one for the whole system (if Y seconds total pass without receiving a message, or Z loops are completed without receiving new data), the system at least warns (if not errors) that the data source seems to be out of new data.