Publish or Subscribe

Here's a quick update for those of you following along.  Last week the goal was to accomplish some system integration, increase the amount of documentation, and continue work on battery packs number 3 & 4. What do I mean by system integration?   Let's take one example, a cars direction, specifically selection of forward or reverse.  Many of the mini-systems in a car do a specific task  and will need to  know about what direction that car is intending to go.  In a conventional car, since the Internal Combustion Engine(ICE) turns only one direction, there are levers that have to be moved to change the gears in the transmission.   Using an AC electric motor, changing direction from forward to reverse is accomplished in the inverter with a command from software.    Since ICE cars are highly mechanical in nature and electric car are much more software based, there maybe higher reliability with electric since there will be less moving parts.   However, the software will be more complex so there is a trade off.  I see Tesla as leading the way in their designs, especially with the Model 3 and the newer model Y.  In our system, comprised of a bunch of 'Helper software processes', each Helper may need to know about some project parameters, such as system direction, indicating forward or reverse.

To accomplish this and plan for more than bench testing, I integrated a publish and subscribe mechanism into the Helper system.  Each Helper process will declare if it wishes to publish or subscribe to a parameter (car direction for example).  The Helper responsible for turning on/off the reverse lights will subscribe to this parameter and gets notified of any changes of direction.   A different Helper that takes accelerator pedal input and changes that to motor commands also subscribes to the this direction parameter.  The user interface/touchscreen Helper publishes the direction parameter, so the user makes a choice and the Helpers get notified and can take the appropriate actions.  Some parameters like RPM limits and such need to be remembered after being changed.  Others like car direction shouldn't be remembered and the last value is what is important.   Of course it took longer than expected to get that all working the way I wanted.    While I was working on that, Joe was quite busy building a foundation for the firmware in the Battery Management System(BMS) boards.

The BMS is essentially an insurance policy for safety, with the added benefit of extending the battery range, by providing a means of making sure each cell has the same level of charge.  In a system with many (96 for a Leaf motor) batteries in series, the car will only go as far as the weakest cell.  Getting all the cells to the same level of charge insures they all will be appropriately discharged at one time. The other part of the BMS  checks that the battery voltage isn't too high or too low, both of which may cause a fire, destroying the most expensive part of the system, not to mention putting the driver and possible passengers at risk.   So the insurance policy in the form of BMS is really important.

The main processor of the BMS boards is at Atmel Tiny841.  This little processors has a built in Analog to Digital, 8096 bytes of code storage and uses very little power in 'sleep' mode.   Writing code for these tiny processors takes a different approach than what I'm doing with the Pi's. It's more difficult to run a debugger on the BMS boards, therefore more testing and verification is needed.  And given the importance of it's task, we want more testing and verification.   Joe has elevated this to an impressive level on this project by taking advantage of additional features of Gitlab (our software repository). These features automate testing and produce slick reports to show percentage of code coverage and pass/fail percentage of tests. I don't currently use this but, seeing this level of automation raises the confidence in end result.  Joe inspires me to do more in the testing area.   Thank you Joe for the inspiration and example.

Increased documentation didn't happen, since I prefer to write software vs. odious but necessary documentation.   I will get to it..

In other news, battery pack 3 is finished and charged, and I'm on step 4 on pack 4, which is the long step.   Next week, the goals are to finish pack #4, make the ten heavy duty cables to hookup the battery to the Leaf motor. Then I can start testing the motor using greater than 10 times the previous amount of power. (Huge grin)  Next week there should be video of the motor spinning along with enough details to make my head spin right along with the motor.  Thanks again for reading.