I know there is a fare amount of work that’s popped up around CAN support. With @olliw42, @mike, @MGeo, @ppoirier, @jpkh, and @siddharth there’s a lot going on. I’m looking at what I can accomplish with non-BetaCopter firmware because I want to make sure it’ll work for someone that’s running release code. In looking through the codebase, I see AP_UAVCAN and it’s derivatives, but there is also CAN code in AP_HAL_ChibiOS. What’s the story with the ChibiOS specific CAN code? I’d like to be able to pickup the data that I otherwise would via Mavlink from a UART. Can I do that with 3.6.5?
For example, does the SLCAN adapter from @olliw42 interact with the code in AP_UAVCAN/AP_UAVCAN_SLCAN.h by @siddharth (and @Pavel_Kirienko)? What is the “SL” in SLCAN? When I get the adapter, should I just be looking at what CAN messages are going across the wire? Are all message sent all the time?
SL is “serial line”, and is basically a bridge to communicate using CAN over a UART.
The SLCAN code in ArduPilot is an alternative to using an SLCAN adapter. Basically it means you can connect to the uavcan GUI directly from the autopilot over USB.
The CAN code within the ChibiOS HAL is basically just how the HAL links to the uavcan library. There’ll be something in the Linux HAL too.
In the hardware CAN devices thread, at the beginning:
and over in RCGroups in the same thread there is a “feature matrix” chart which shows what is supported where.
OK. That makes sense. As for “mavlink-esque” data, I would need the Mavlink node which I believe is BetaCopter only.
right and I said over there, Mavlink node is missing from the matrix.
So you did not understand over there? CANbus has it’s own messages it is not Mavlink.
I know it has its own messages. That’s why I said “mavlink-esque”. I don’t know of any other way to describe it. Ok, let’s call it “telemetry+” then. For example, if I wanted to make an OSD that sat on the bus, or a companion computer which is on the bus too. I need that level of detail.
The bridge is like an SLCAN for MIssion Planner. Just like Mission Planner when plugged into an FC can read the parameter list from the FC, the bridge can allow Mission Planner to "see’ the CAN devices, connect to them, and read the messages from those devices, showing up as parameters which can be modified and written back.
Just like when you download the parameters from your Pixhawk when you connect, with the bridge you can connect to say a CAN ESC and read it’s messages.
If you are talking about making your own CAN devices that is not a simple task. Each CAN device has it’s own microprocessor to keep track of it’s messages and respond to requests on the bus for it’s data. SO it is not as simple as say a serial stream of data being sent from one device to another with some kind of handshaking.
Theoretically a CAN gimbal could request CAN GPS data directly without going through the flight controller at all.
You could use the UART node to connect telemetry data from the Pixhawk to your OSD, with the Universal node “translating” or more correctly maybe interfacing CANbus to the serial interface of the OSD. This is more of a tunnel where it is not designed to present anything of the OSD to the bus.
Am I answering your question or making it worse 
That last part is what I wanted. Tunneling. That’s a BetaCopter thing, right?
yes. Olli has implemented tunneling in betacopter, @MagicRuB has a different implementation in a PR to ArduPilot master, but it’s not ready/merged yet.
Hello @davidbitton and welcome to the small group of uavcan enthusiasts , that will certainly gain popularity as we get acces to affordable components and a better integration to ArduPilot.
that explains things. I saw a reference to @MagicRuB in a code file I was looking at last night. Perhaps for my use case, a UAVCAN Telemetry node would be more appropriate. As I understand, Mavlink can be a bit verbose, so stripping it down to the bare necessities would produce less traffic on the bus. Should I talk to @Pavel_Kirienko about adding to the UAVCAN spec first? I can always work with @MGeo’s setup to build on.
Take a look at this, I think this is a milestone in the UAVCAN adoption:
AP_Periph is actually quite a clever idea. Ultimately I see it as a way to share device drivers between the flight controller code, and canbus peripherals. So if we add a new compass/airspeed sensor/lidar etc, the driver only needs to be written once.
yep. I was looking over @night_ghost’s MinimOSD rewrite, and it’s pretty clear what info is required for an OSD node.