UAVCAN: Vendor specific data types not dsdl-compiled

[olliw42]

Issue details

The build system does not seem to support vendor specific UAVCAN data types, i.e. dsdl files placed in modules/uavcan/dsdl are ignored, only those in modules/uavcan/dsdl/uavcan are compiled by the dsdl compiler.

This is probably a very simple change, but I failed to find my way through all the .mk, CMakeLists, wscripts, and whatever files :).

Would be nice if the build system could support vendor specific data types. Maybe by checking a folder outside the uavcan module.

Version

AC3.6 dev

Platform

[ ] All [ ] AntennaTracker [x ] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type

IMHO irrelevant

Hardware type

IMHO irrelevant

Logs

IMHO irrelevant

[EShamaev]

http://uavcan.org/Implementations/Libuavcan/Tutorials/8._Custom_data_types/

More specifically: You should not create it inside the libuavcan’s DSDL directory (libuavcan/dsdl/...) in order to not pollute the libuavcan’s source tree with your custom data types.

In my opinion, if some vendor specific data types are to be integrated in AP, then separate compilation line should be added. Meanwhile for the experiments as the path to your messages are not strictly defined - please do manual compilation.

[olliw42]

I think the UAVCAN Gui Tool could be an example: It offers a folder outside of the standard dsdl directory into which all vendor data types can be placed, and henceforth it just uses them. Works nicely (except that for win users the folder is at an odd place, but that's not the point, you may want to make a better choice though) . I think you could copy that, i.e., define a folder somewhere into which all vendor data types are to be placed, and have that folder hardwired into your build system. Would be quite user friendly, and sounds like a minor change to your build system

"manual compilation": no idea what you're saying, probably above my pay scale :)

glad to see some response, btw :)

edit: Ardupilot may want to add their own set of messages too and not fully depend on the standard data types, this would accomodate that easily too

.../apvendortypes/ardupilot.org/ .../apvendortypes/eshamev.org/ .../apvendortypes/olliw.eu/ .../apvendortypes/... :)

[magicrub]

DING DING DING!!!!! I have a solution:

Vendor has: ~/uavcan_vendor_specific_types/mydevice/Mypacket.uavcan

We put it in: ardupilot/modules/uavcan/dsdl/mydevice/Mypacket.uavcan

And the ArduPilot source looks like:

#include <mydevice/Mypacket.hpp>
...
uavcan::Subscriber<mydevice::Mypacket, MyPacketCb> *myPacket_listener;
myPacket_listener = new uavcan::Subscriber<mydevice::Mypacket, MyPacketCb>(*node);

now, the obvious solution is to do what hex did by putting it in com/hex/foo but I was handed some hardware that was compiled via uavcan.org directions using the ~/uavcan_vendor_specific_types/ method and all attempts to talk to it failed CRC checks due to namespace mismatch.

So, short answer is... ~/uavcan_vendor_specific_types/ simply doesn't have any namespace! LOL

The real solution is to build an AP_Periph and put the .uavcan files in a vendor area like what Hex did here: https://github.com/ArduPilot/ardupilot/tree/master/libraries/AP_UAVCAN/dsdl/com/hex/equipment/flow

It's probably safe to close this. It's old and I don't think there's going to be any new movement on it

[olliw42]

closing it since really outdated :)