Future: Foreign object serialization formats about public_regulated_data_types HOT 7 CLOSED

from public_regulated_data_types.

@pavel-kirienko @antoinealb You will want to look at this issue:
https://github.com/mavlink/v2_playground/issues/1

It has a complete table. We're currently revisiting the whole message definition on the vehicle in collaboration with Dronecode & 3DR. There was also some interest to have the same messages on CAN, so it would be a big plus to have native support in UAVCAN for the message format. So far Cap'n Proto seems to lead in terms of features and efficiency.

from public_regulated_data_types.

First stab, at 3DR's request: https://github.com/UAVCAN/dsdl/tree/foreign_object/uavcan/foreign_object

from public_regulated_data_types.

@pavel-kirienko I'm interested in reviving this foreign_object concept for carrying multiple protocols over CAN. I see your branch with the generic 1024 byte buffer. I'm surprised FORMATS does not contain MAVLink? I think that's worthwhile. I definitely have a need for it.

from public_regulated_data_types.

You can add it to Format.uavcan. However I wonder if there is really interest in putting this kind of support in the standard, as the decoding of the payload will probably be application specific anyway.

from public_regulated_data_types.

@antoinealb I find it useful and it's not just me. Why not include a generic interface like this in the main spec? I don't see a downside. I'll PR the branch from @pavel-kirienko

Having a bridge is very useful. Another bridges that would be helpful is I2C over CAN. I know ArduPilot would like that. Helps with migrating devices.

from public_regulated_data_types.

Revised implementation at #40

from public_regulated_data_types.