We have realized that there is a consistent pattern / architectural need where an “event” occurs in the system and an external component (be it a software component on the network or a ground control station) cares about seeing all those events.
These events should also encode optional meta-data, which is not transmitted but available through a dictionary - like the error event “not arming because there is no GPS lock” could be encoded with ID 240345 and the error message could be available in english and more user-interface languages.
In contrast to text messages events should include a delivery guarantee so that the sender and receiver can be certain that they received all events and in-order. This suggests the need for an instance counter or alike.
Another example for an event is a camera trigger or sensor fail event - these might not have textual descriptions but maybe a more detailed error description or a link to a website.
Events will commonly carry parameters. I’m not yet clear how to encode this, but a generic event could have 1:N parameters. I’m sure people have built something like this for other applications like websites or apps - are there good examples?
I really like the QP Active Object framework. It’s actually intended as a framework to replace a traditional RTOS, but it can maybe help for inspiration. All the code is open source and the author has written a great book on it which can be downloaded for free (download link). Chapter 4 describes the implementation of the event processor.
The inefficiency of JSON is because it runs Javascript in a virtual machine.But that is by design since your browser is the OS for most Web content. With JSON, one could leverage Node.js and a lot of different apps to present the data (much more active development).
[bat: 15.2]
[alt: 13,456]
ASN.1 is good, but binary encoded and then you need a MIB and the traversal can be complex (as well as having to maintain a separate tools for processing. It’s tree structure may be more suitable for what you’re doing just based on the events you’ve outlined. On the other hand, you will have more development and less to leverage.
I’ve use both object schemas for widely varying system software (SNMP Mibs and Network drivers versus Dynamic HTML content), it really depends here on whether you want to leverage Web and client/server side development today - much more developers with JSON then ASN.1
I think the most critical parts for events in an UAV system are:
limited radio resource
limited hardware resource for on board components as event receiver.
Radio link between UAV and ground station is far from idealism, especially when UAV is far from base and moving fast and even the ground station itself. Packets can be lost due to signal fading, multi path interference, or simply shadowing. Radio frequency budget of air interface is very limited on an UAV system, and we need to save energy for every bit.
If we can transmit a message with 10bits, we do not do it using 12 bits. The more bits used, the more risk is taken for packet receiving failure that will lead to expensive re-transmission or broken message. Unlike landline, encoding efficiency comes the first priority in this situation. Unless user experience of radio link quality is totally ignored, XML/JASON is less optimal in this case, which i believe is not the design target of PX4 system.
ASN.1 is not that complex to implement in my opinion, as it is just designed for resource limited embedded/real time system. Also quite some open source ASN.1 projects out there for reference or integration and i do not see much efforts needed to adapt it.
The XML/JASON stuff can come in after the message landed - where an ASN.1 to XML bridge can then mediate the event to powerful computer and landline based network world, seems to be a more reasonable solution from then.
Its not about the count of developers to select a right technology - we tend to lower cost of development, but not at the cost of degrading user experience too much, especially for an emerging new industrial system.
I understand the issues of link budget very well; and there are other issues at work there so perhaps my understanding of the problem Lorenz originally posited is incorrect.
My understanding of the issue is to reduce MAV encoded even/text messages from the air to the ground and v.v. by minimizing (or removing all together) any text messages from the firmware and qgc and subsequently replacing that with an event code and/or bitmap which would still go over MAVlink, but substantially reduce the tput requirements. In that case, one could maintain a dictionary which maps these event/status codes to human readable form and separate the interface from the implementation. I wondered how i18n support would work since in both qgc and px4 firmware has text in the code (one thing we needed to remove for link budget purposes when using mavlink for amateur rocketry).
The use of ASN.1 would first require a tool to convert event/mask numbers to BER/DER encoded binary tree format; and then you would then need an additional table to map these tree elements back to text (this is why, in the context of SNMP even if you have ASN.1 objects you need to load a MIB to map them to useful measures/events).
When using JSON, no additional tools are required - one could have a schema which maps all of the event and status codes to a JSON dictionary, O(1) lookup time and human readable format with no additional tools required. Since UTF is supported by JSON, one could have multiple dictionaries for Cyrillic, Chinese, Korean, etc.
JSON/ASN.1 are just tools, I’m not in love with either of them, but picking the right tool for the job is also a function of time to market.
I may or may not correctly understood OP’s question, as few context was mentioned, even not sure if the event interface is something separate from MAVLink, or something on top of it. So just some open diverse talks here.
ASN.1 was called out as OP mentioned 1:N event parameters needs to be encoded besides of text msg replacement. I just have a check on MAVLink and seems years back Lorenz already considered different binary encoding including ASN.1 in mavlink v2.0 (not sure how it progress though). So it might be another topic.
However some misleading information may need clarify.
ASN.1 and MIB are separate concepts. ASN.1 is just an encoding rule, while MIB is more a telecom network management modeling concept. MIB may use ASN.1 as a representation, but ASN.1 does not rely on a MIB to work as encoder/decoder.
MIB seems to be an overweighted concept to be used for small system like UAV. That been said, it will be interesting to see how these status information should be modeled in sense of UAV management? One may endup with nested dictionary for simplicity purpose, rather then a flat structure.
ASN.1 tool is something help to generate encode/decoder code for you, which, in my view is more of pros rather than cons, as you can then simply focus on the data themselves.
1/ Mavlink packets too short to contain needed data?
2/ No packet receipt acknowledgement?
3/ Delivery not guaranteed?
4/ No stringent packet tracking - might miss the occasional packet?
5/ Provide richer, more useful error and event messages with debug metadata (Airspeed sensor fail because V = %f m/s; should be < 15f)?
Some of these issues are similar to issues in Iridium communications. Very limited space, high latency, important messages, and the sender needs to know if the message was received intact by the satellite.
In general, you would need a routing table (who needs to see this message?) and then the sender keeps retrying until everyone in the routing table has positively awk-ed receipt of the intact non-garbled message. At that point the message is cleared from the critical transmission cue.
Doesn’t mavlink SERIAL_CONTROL_FLAG_RESPOND provide some of the needed functionality?
My suggestion to JSON vs ASN.1 battle - may be use http://msgpack.org ? It is compact, supported by most programming languages and can be easily parsed both on C and Python
How corruption tolerant is msgpack_unpack(sbuf.data)? Or I guess we would use a checksum, and any corrupted packets would be rejected before hitting msgpack_unpack?
