Add Support for BMS Tiltback

[Relys]

    (var bms-fault-codes '(
        (NONE . 0)
        (BMS_COMM_TIMEOUT . 1) < 2 SECONDS. Not currently used in Refloat. Not sure where to put to notify user.
        (BMS_OVER_TEMP . 2) CELL_OVER_TEMP +10
        (CELL_OVER_VOLTAGE . 3)  bms-vmax-limit-start
        (CELL_UNDER_VOLTAGE . 4) bms-vmin-limit-start
        (CELL_OVER_TEMP . 5) bms-t-limit-start
        (CELL_UNDER_TEMP . 6) ; Not used
        (CELL_BALANCE . 7) <= 0.5v difference. Not currently used in Refloat. Not sure how to alert user.
    ))

The other values are from conf-get function in lisp. They can be found in Motor Config -> BMS. While we want the limit boxes unchecked, we can use these fields to customize limits for our own use. Note: I also check if any limits are enabled and disable them (since we want to do that with pushback not limiting motor current).
'bms-t-limit-start      ; Temperature where current starts to get reduced
'bms-vmin-limit-start   ; VCell where current starts to get reduced
'bms-vmax-limit-start   ; VCell where regen current starts to get reduced

Now package.lisp spawns a new process bms-state-loop which handles looking at user config values and BMS data to determine BMS state. It will search for a bms-can-id within first 10 seconds of boot and load the bms-state library if found. BMS faults are stored in an u32 as bitfields. They are sent to the main Refloat C loop with ext-bms-set-fault. In the areas that handle pushback bitfield checks with bool bms_is_fault_set(uint32_t fault_mask, BMS_FAULT_CODES fault_code) are now performed. Minimal code was touched in Refloat itself besides the additional checks, and BeepReason was expanded to handle additional error states.

[lukash]

You're not handling the Cell Balance and Comm Timeout faults on the C side and you removed the Cell Under Temp handling altogether (I feel this should be addressed in some way).

The commit message is chaotic. Is it really signed off by @surfdado? Please add a Feature: git trailer for the changelog.

[Relys]

Added some changes, but am unable to test right now since my board is down.

I added beeps (no tiltback) for balance and communication errors. I also re-added CELL_UNDER_TEMP when cell goes below 0 degrees (as per recommended by Battery Mooch).

Instead of keeping logic where I loop through bms voltages, I was able to get accessing the min/max cell values through lisp pulled upstream into main bldc branch: vedderb/bldc@07128ea

Instead of hard coding a specific version, I can just check if that function exists before continuing:

(if (eq (first (trap (get-bms-val 'bms-v-cell-min))) 'exit-ok)

[lukash]

Thanks for the update. I unresolved some comments which I felt weren't addressed well enough. I also think you missed 4 comments from the previous review because GitHub hid them... For those I made new comments in the current review, so you can just react to my current comments and ignore the old ones...

Sorry about the amount, but it is what it is 😅

And thanks for upstreaming the v-cell-min/max values, makes it cleaner on our side.

[lukash]

Unaddressed comment from last review, 0.5 seems way too high to me. Not sure what the value should be though.

[Relys]

That's what dado recommended. Cells dip especially on split packet and where there's noise.

I'm wondering if I should just remove this entirely? Or maybe only beep when the board is not running and then we could lower that threshold?

[lukash]

Oh, I see. True that properly judging how the pack is balanced should only be done when idle, it can jump around a lot while riding. We could check it only when idle, question is what to do, is the board supposed to beep in that case? Is it supposed to beep continuously or once in a while? Maybe seeing the battery is imbalanced in the UI would be enough? But then, the dedicated BMS page in VESC Tool might be a better place for that...

FTR, propagating e.g. the engaged state to lisp and moving more of the logic over to there is exactly what I don't want to do.

So this brings me around to whether we should do anything at all, and if we should do anything, seems just checking the balance is not totally out of whack, like, having a 0.5V difference, makes some sense to me 😀 .

In that case, please add a comment along the lines of:

// Only check if the balance is not completely off (in idle or while riding), not meant as a proper balance check

[Relys]

Right now I'm only checking if the board state is READY (not RUNNING) in main.c: https://github.com/lukash/refloat/pull/27/files#diff-e0cf5b28d9b6b600f0af2bc78e8fd30ec675fd731a5da86f0c4283ffc0e40176R1497

Same for BMS connection issue. Should BMS connection actually be checked while running though, and balance only alert while idle?

[lukash]

Just a note, looking at this 15 degree constant being pretty arbitrary. We should at least figure out a place to document these numbers so that users know how it works...

(I don't like the arbitrary number but don't have a better suggestion, seems reasonable at least to start with)

[Relys]

yeah idk +15 just seems like a reasonable overhead. for cell max 45 +15 would be 60 on bms (and bms is next to cell pack so you don't want it getting too hot) I could also just not look at this value.

[lukash]

I don't know, makes some sense to warn about this, if someone's discharge bms starts catching fire... I think we just need to set up some documentation page for this stuff...

[lukash]

And please add the Feature: trailer to the commit description, that'll be turned into a changelog record (so phrase it that way) with an attribution to you.

[Relys]

Added another update. I'm unable to test right now still, so lmk if there's any errors in lisp or something.

[Relys]

Also just added support back in for 6.05 (since we don't have 6.06 API changes yet) after talking to @surfdado and Fungineers.

[Relys]

Another change to allow disabling this feature by setting Motor CFG -> BMS vmin-limit-start, vmax-limit-start or tmax-limit-start to 0.0

[lukash]

Another change to allow disabling this feature by setting Motor CFG -> BMS vmin-limit-start, vmax-limit-start or tmax-limit-start to 0.0

Hmm. I'm not sure about this, what's the motivation? FWIW IMO it'd be better if you brought up significant changes like this with me before doing them. If I have an issue with them, it makes me feel bad to bring it up because I don't want to make you go back and forth.

You can turn this BMS alerting functionality off by setting BMS Type to None, right? So what's the motivation?

What'd make more sense to me is disabling that one particular check by setting the limit to 0 (but we don't have a config value for every check we do that'd allow us to disable them individually 😞).

[Relys]

Another change to allow disabling this feature by setting Motor CFG -> BMS vmin-limit-start, vmax-limit-start or tmax-limit-start to 0.0

Hmm. I'm not sure about this, what's the motivation? FWIW IMO it'd be better if you brought up significant changes like this with me before doing them. If I have an issue with them, it makes me feel bad to bring it up because I don't want to make you go back and forth.

You can turn this BMS alerting functionality off by setting BMS Type to None, right? So what's the motivation?

What'd make more sense to me is disabling that one particular check by setting the limit to 0 (but we don't have a config value for every check we do that'd allow us to disable them individually 😞).

"You can turn this BMS alerting functionality off by setting BMS Type to None, right? So what's the motivation?"

You assume too much haha. No that's not exposed. @surfdado mentioned wanting some way to disable this feature, and so this was the only solution I could come up with the variables exposed in Lisp. I could take a look and see if BMS Type is exposed on the C side maybe? Edit: I checked and nope.