A new ‘question’ of sorts, but more of a probe into community interest.
The location of this post may be incorrect, and so please inform me if this is better suited to a GitHub issues post (I see feature requests there occasionally). In addition, the Plane category seems rather an odd location - if there’s a category for libraries or features that I glossed over, I will move this elsewhere.
I am interested in integrating a communication-enabled Battery Management System (BMS) with an airframe power system. The BMS in question is commercially available, manufactured by Energus Power Solutions: the Tiny BMS s516. It can handle my power requirements with plenty of overhead, and has the necessary features (balancing, charge control, alarms) and - most critically - digital monitoring. The BMS is fully configurable by provided software - so, while it is not open source, the basic amenities to utilize it are provided, and the necessary commands to interact with it are specified.
The interface offered by the BMS is a simple UART header, which serves as a carrier for a partial MODBUS implementation (only the software level is MODBUS, physical layer is regular UART).
I see that in some way, shape, or form the Ardupilot code base has brushed up against MODBUS in the past, per this repository. So, given an available MODBUS- compatible command set, it is a single call away from getting all the registers of the BMS (cell voltages, total pack voltage, state of charge, current, temperature(s), faults, etc). The full datasheet of the BMS can be found on the page above, or here.
Naturally, such a library/driver would most at home in the AP_BattMonitor family, functioning much like the SMBUS, Maxell, and Solo battery drivers which support similar levels of battery monitoring.
Given the somewhat costly nature of the BMS, I don’t expect many to ‘embrace’ the feature on the scale of SMBUS-enabled batteries, and so I am certainly willing to be the only one putting time into the creation of the feature. That said . . . I actually have no idea where to start. My interactions with the ArduPilot code base until now have been limited to simple modifications here and there, never having to toy with the overarching structure of the thing. In fact, my strongest languages are in Python, Java, and MATLAB (say what one will), and so I am starting at square 1.5 for C code that does more than loop mindlessly as an Arduino sketch. I say 1.5, as I am currently taking a real-time systems course that is heavily C-focused, though with vxworks as an RTOS.
What I’m asking here, is if someone is interested in this idea, and if they are willing to direct me on the proper development path for understanding the code base, the Ardupilot coding practices, and how best to integrate with the AP_BattMonitor and AP_SerialManager family, implementing the (I assume derelict) MODBUS library. Do things need to change for the up-and-coming ChibiOS transition? Is this too resource-intensive for a firmware nearing the 1MB flash limit? There are many things I don’t know about charging headlong into adding a new feature, and I’m afraid of stepping on others’ toes.
I have another option worth mentioning, which is the usage of a little 32u4-based microcontroller to fetch data from the BMS using the Arduino (. . .) MODBUS library, and effectively ‘faking’ a battery supporting SBS (Smart Battery Specification) by taking advantage of the pre-existing Maxell and Solo battery drivers. That said, I’ve spent the past couple days poking around forums, and I’m finding a lot of uncertainty regarding the usage of Arduino’s Wire library in an SMBUS environment. Evidently not many have successfully attempted to mimic SBS with Arduino as a starting point. Additionally (and more critically), it adds to the number of failure modes by adding hardware and software. As such, I first brought up the native MODBUS option, directly integrated with ArduPilot.