Hi, I am using Arduino MKR Zero with its CANBus shield and 107-Arduino-UAVCAN library to read my Tattu smart battery (it has BMS). I was curious that I received raw data when I was using normal CAN library but I can’t get any data when I was using UAVCAN provided library. Is there anything that I might do it wrongly or skip when using the 107-Arduino-UAVCAN library (I would say my wiring is correct)?
I asked battery provider’s technicians, they said they are following UAVCAN protocol following by BMS subscription, and yet they didn’t encrypt the UAVCAN message for the smart battery. So, I am curious why I didn’t receive any data using the 107-Arduino-UAVCAN library.
Do I need to code it by myself using that library (107-Arduino-UAVCAN) as a reference or I can just use the example in the library directly?
This is probably because the vendor is actually implementing the legacy UAVCAN protocol, which is now maintained separately under the name of DroneCAN. Use that instead.
I don’t think they are using legacy UAVCAN because Not even UAVCAN GUI Tool can recognise the BMS. I asked them regarding to this issue and confirm with them already, they said they are using UAVCAN but not telling me which version of UAVCAN. They told me that UAVCAN has many versions and they are using “BMS type”, they told me like this and I can only assume they said they are using UAVCAN v1.
Anyway, Thank you for your time to reply, much appreciated.
Sorry to interrupt you again, Tattu team has replied me as “we also do it according to the data structure of UAVCAN. UAVCAN defines the data structure and does not define the protocol content. The content of the agreement is defined by ourselves.”
I believe they claimed their BMS is using UAVCAN frame but they have different structure of messages in the frame.
Is that possible? The UAVCAN also defined the the content in the frame right, like which bytes are for voltage and so on.
And they are stressing that they are using UAVCAN all the time but they cannot answer my question of the version of UAVCAN that they are using.
I don’t mind answering questions but I am concerned that maybe you are not spending your time in the most efficient way. Why not simply direct these questions to the vendor? I never seen their products and I have no idea how they implemented UAVCAN. I am happy to help with the protocol, its architecture, system design, official libraries, etc., but I cannot help you debug a random product that implements (or claims to) UAVCAN. If the vendor doesn’t understand what they are using, they would be welcome to seek help here.
This looks like the message frame structure for UAVCAN v0, which (as Pavel said) is currently maintained under the DroneCAN project. However, it seems that these batteries are not very well documented so I’m not sure if it will work for you - best of luck, though! You can probably also ask the Ardupilot community (forum or Discord) to see if anyone there has experience with these batteries.
Tattu have basically implemented v0/DroneCAN incorrectly. I have an email thread with them somewhere, but basically Tattu need to fix it in order for their battery to be properly useable (as well as the broken implementation there’s silly things like hardcoded node ID so you can’t use more than one battery at a time). I think px4 merged a work around so that you can use a single battery (at the expense of any other can usage). Ardupilot didn’t.
Might be a dumb question, but are you sure you have the correct CAN settings? Same CAN standard (2.0B vs FD) and same baud rate? I have had those issues in the past
