Regenerative Braking Logic Emulator with Battery Charge-Acceptance Limits

The problem

Regenerative braking returns energy to the battery, but a full, very cold or hot battery cannot safely accept charge. The vehicle controller must blend regen with friction braking so the rider always gets the braking asked for, whatever the battery state.

Objectives

• Model vehicle speed and braking with a simple longitudinal model in firmware
• Compute a regen power limit from cell voltage and temperature
• Blend regen and friction braking so total braking always meets the demand
• Enable the charge path through the BMS relay only when regen is allowed

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

One-pedal driving

Lifting off the accelerator below a coast point commands regen, so the pot acts as both throttle and brake request.

Charge acceptance

Near full charge the cell voltage approaches its 4.2 V limit and charging must taper; at low temperature charging risks lithium plating, so regen is reduced or blocked.

Brake blending

The controller gives as much of the braking demand as possible to regen and the rest to friction braking, so the rider feels the same deceleration.

Emulated speed

The kit has no wheel-speed sensor, so speed comes from a model: mass times acceleration equals drive force minus braking minus drag and rolling resistance.

Step-by-step guide

1. 1

   Requirements and safety

   Define pot zones: below 20% is regen demand rising to maximum at 0%, 20–25% is coast, above 25% is throttle. Define the regen limit rules: full regen below about 4.0 V and in a safe temperature window, tapering to zero at 4.2 V, and zero below about 5 °C or above about 45 °C (set your values from the cell's datasheet). Note lithium cell care: check polarity, never short the terminals and do not leave charging unattended.

   Checkpoint: A written rule table and limits, checked against the cell datasheet.

2. 2

   Board setup

   Set the DIP switches for the Smart BMS unit, battery, charging unit, charge/discharge relay, motor driver, potentiometer and LCD. On the main controller configure the 72 MHz clock, a 20 kHz PWM channel for the motor driver, ADC on the pot and a UART for the link to the BMS unit. Check the kit schematic for how the two controllers are connected and which pins drive the relay and read T-sense. Confirm the battery polarity before switching the BMS on.

   Checkpoint: Both controllers run and exchange a test message over the link.

3. 3

   BMS firmware

   On the BMS STM32 read cell voltage and T-sense with the ADC, average and convert to millivolts and degrees C using the divider ratio and the sensor's curve. Send them to the main controller every 50 ms, and accept a command to open or close the charge/discharge relay. Keep a hard rule in the BMS that refuses charging above 4.2 V regardless of commands.

   Checkpoint: The BMS OLED and the main controller's console show the same cell voltage and temperature, matching a multimeter.

4. 4

   Vehicle model

   In a 100 Hz loop on the main controller, integrate speed from the net force: drive force proportional to throttle, minus regen and friction brake forces, minus rolling resistance and aerodynamic drag that grows with speed squared. Use realistic parameters for a small electric scooter, such as mass with rider, wheel radius and maximum motor force, and write the model in fixed-point arithmetic. Clamp speed at zero so braking never drives the model backwards, and log speed for later plots.

   Checkpoint: Full throttle accelerates the modelled scooter to a plausible top speed, and coasting slows it gradually.

5. 5

   Regen limit

   Compute an allowed regen fraction from 0 to 1 using linear tapers: full regen in the safe voltage and temperature window, falling to zero as the cell approaches 4.2 V or leaves the temperature window. Add hysteresis at each boundary so the limit does not chatter when a reading sits on the edge. Convert the fraction to a maximum regen force, and also cap regen power, force times speed, so that braking near standstill stays realistic.

   Checkpoint: Logged regen limit tapers correctly as you change the simulated input values in a test mode.

6. 6

   Brake blending

   Take the total brake demand from the pot's regen zone. The regen force is the smaller of the demand and the regen limit, and the friction brake supplies whatever remains, so their sum always equals the demand. Show the split with the RGB LED: green for regen only, amber for blended and red for friction only, and give a short beep when the battery blocks regen entirely. Log demand, regen and friction at 10 Hz to prove the sum is conserved.

   Checkpoint: Total braking force equals demand in every case in a logged test sweep.

7. 7

   Charge path

   When regen force is above a small threshold and the BMS reports that charging is allowed, command the BMS unit to close the charge path from the charging unit, as a stand-in for regen energy reaching the cell; open it otherwise. The cell's actual charging current is not measured on the kit, so track modelled regen energy in watt-hours by integrating regen power from the model. Keep the BMS-side 4.2 V rule active regardless of what the main controller asks.

   Checkpoint: The relay closes only during allowed regen and always opens when the cell is near 4.2 V.

8. 8

   Motor output and display

   Drive the motor duty in proportion to modelled vehicle speed so you can see the emulated scooter speed up, coast and brake. Update the LCD with speed, regen share, friction share, cell voltage and cell temperature a few times per second, using two alternating screens if one does not fit. Check the motor slows visibly faster when braking than when coasting, and that a blocked-regen case still slows it at the same rate through the friction share.

   Checkpoint: The motor slows faster when regen plus friction braking is applied than when coasting.

9. 9

   Test scenarios

   Define a repeatable drive cycle: accelerate, cruise, then brake to a stop, controlled by a scripted pot sequence or by careful manual repetition. Run it at three battery states: mid charge, near full, and with a simulated cold temperature injected through a test command. Do not cool or heat the cell. Log speed, demand, regen, friction, cell voltage, temperature and relay state at 10 Hz, and repeat each case at least three times.

   Checkpoint: Plots show regen share falling as the cell nears full and blocked in the simulated cold case.

10. 10

    Report

    Document the vehicle model with its parameters, the regen limit rules and their sources, the blending logic, the safety rules in the BMS firmware and the test results. Present drive-cycle plots for each battery state and the modelled energy recovered per cycle. Discuss how a real VCU and BMS share this decision over CAN, with the BMS publishing a charge current limit that the VCU must respect, and what your emulator leaves out.

    Checkpoint: A report with drive-cycle plots and a demonstration.

Testing & validation

• Cell voltage and temperature compared with a multimeter and the BMS OLED
• Brake force conservation: regen plus friction equals demand in all cases
• Relay behaviour at the voltage and temperature limits
• Drive-cycle plots at different cell states

Expected results

A working emulator that shows how a vehicle controller blends regen and friction braking within the battery's charge-acceptance limits, with logged drive cycles and a hard BMS-side charge limit.

Take it further

• Send the BMS limits over CAN in the format a real VCU would use
• Replace linear tapers with a current limit based on an equivalent-circuit cell model
• Add a brake-light output on the general output relay

Viva and review questions