https://en.wikipedia.org/wiki/CANopen
Many more things besides auto's use CAN. One of my current projects involves exercise equipment that internally speaks CAN Bus. There is great support in Arduino for interfacing with stuff like this.
That actually sounds perfect for a project I've been working on. I think changing your environment really helps with thinking, so I added wheels to my desk/workbench at home. I've been trying to find parts that are inexpensive, reliable, and have enough torque to move an entire workbench, but they are near impossible to find.
My first goal is to add automated raising and lowering of the table surface so I can switch from sitting to standing. Then I want to replace the casters with actual motorized wheels. The plan is to run the whole thing on a bunch of 18650s and use that as my UPS for the electronics on my workbench as well.
Plus I think it would be hilarious to build a desk that you can control from afar, since you have to be at one to use it anyways.
Spot the Orderly?
The bizarre story was we had an employee that was diabetic, and she passed out one day. When the paramedics arrived, they found her already sitting in a hospital bed.
There's a relatively recent extension called CAN FD that can go faster, as can the FlexRay protocol, which is sometimes used instead of CAN.
But not for the self-driving car generation, where the sensors are higher-bandwidth.
As I recall, Mobileye worked around this by just putting the detection intelligence with the camera and sending back synthetic data.
- CAN is very slow despite high baudrates. As used in automotive max 40% of all bits are actual databits. That value is for frames with 8 bytes. For 4 bytes that drops to 25% so people avoid these frames. That means in practice one gets only 1500 frames/s at a typical 250kbps.
- a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.
- CAN-B error detection mechanism has holes in it due to bit-stuffing. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.
- CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates.
So the take-away here is, yes, CAN sucks, quite badly. CAN-FD improvements really only suit niche applications.
It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus.