Thoughts about System/Electronics Architecture

I've spent some time thinking about what I liked about the previous architecture and what I didn't.

I'd really like to have a proper battery management system (BMS) PCB, and to get everything on a CAN bus this time (and actually use it). This is how I currently imagine the electronics system architecture will look:

Last year, one of our design goals was for the robot to be reusable in future competitions. However we've already decided that we now want to change enough of the pieces that we'd essentially be redesigning it from scratch anyway, and so may as well make a new one so that we have the old platform to use for testing in the meantime. We also said we'd have a break before starting development again, but just a week after the 2024 competition we both found ourselves working on concept designs and other ideas for next year. Seems we have a pattern of saying one thing and doing another...

Design Goals

As I write this now, because they will likely shift over the next few months, the main design goals for the new robot are:

Mecanum wheels, we both hate how they look, but we can't deny how the ability to drive sideways on some challenges is incredibly useful. So the answer in our minds to this conundrum is swappable wheels so we can choose the best drivetrain for each scenario. The only thing is, to drive mecanum wheels we now need 4 motors rather than 2 since we need individual control of all 4 wheels. This at least rids us of the complicated timing belt setup we had before, but means we need some new electronics to drive these, and probably a new pi-hat and motor encoders as well. The motor controllers will therefore be split into 4 separate boards which should allow them to be simpler and make the mechanical integration more straightforward. Time will tell if that ends up being true in practice.

We want to try and maintain the serviceability that our last design had, and even improve it by making the raspberry pi ethernet and USB connections more accessible.
I'd also like to make sure we're using more robust communication protocols, ideally everything between boards should be fully differential and where possible include error detection built in. We didn't have too many issues last time with this, but ensuring we don't this time would be nice.

Finally we'd like to capitalise one the more exotic sensors we added last time but didn't properly utilise, in particular the LiDAR, to allow some more advanced automated navigation (not just dead reckoning/odometry).
There are plenty of other plans at the moment, which I wouldn't exactly classify as design goals/requirements per se, but have been discussed in the hope that they will make our lives much easier later on. A couple examples are: an NVME SSD for the Raspberry Pi to make it more reliable, and adding an extra WiFi dongle for connecting to the internet at the same time as hosting its own network.

So, for now I'll be getting on with some new custom motor control electronics, more detail on that to follow soon.