b]Power control:[/b] I found that my idea of simply turning non-Master node DC-DC converters on and off based on the value of (CAN-hi+CAN-lo)/2 was not adequate. With just two nodes (and even with 3 - mostly), with Master off and the non-Master transceiver in standby (CAN-hi+CAN-lo)/2 drops low enough to turn off the non-Master converter. With four nodes (one off, and 3 in standby) it does not. I have therefore added an NPN low-side switch to the control line in the non-Master converter that gets turned on by a digital pin of the Nano. As before, (CAN-hi+CAN-lo)/2 turns the converter on, but when the non-Master gets the CAN message to shut down, the converter's control pin gets pulled low. (A small capacitor is also needed so that the shutdown is not so brief that the Arduino just goes into a brown-out reset.) I also wired up an old 18.5V computer brick so that I didn't have to go down to my "dirty-work" shop's 24V batteries to test this (which I hadn't been doing routinely enough). Now, the DC-DC converter's are always the primary power source and I should, hopefully, spot screw ups when they happen rather than a few weeks later.
Revision organization: To keep track of what I'd been doing, I sequentially numbered each node's sketches as they got modified, and archived the older ones. Then I discovered a bug, I don't even recall now what it was, and had to backtrack through that archive to find what change had caused it. BUT, I had no decent way to know which revision number of NodeX was really concurrent with NodeY, and mismatched programs might not work for reasons having nothing to do with the bug. I've therefore changed how I'm tracking things, but really don't know if there isn't a yet better way to do things - suggestions would be welcome. What I'm doing now is that each day that I work on software I copy all elements of the previous version into a fresh, dated folder. If I then discover a problem and have to figure out when it got introduced, I will at least have coherent sets of nodes.
High current circuitry: This mostly has naught to do with Arduino, except that some functions will be handled by the AuxNode as the Roboteq doesn't have quite enough pins. Nevertheless, I've included schematic and PCB layouts in hopes that you can spot weaknesses. A couple notes are in order: (1) safe use of the Roboteq requires addition of a high-current contactor, fuse, pre-charge resistor etc.; I'll also have a plug connected to a wrist lanyard as an emergency stop device, (2) in order to use IR motor compensation at low outputs accurate motor currents are needed, but the Roboteq estimates motor current as (battery current*PWM on fraction) so gets less and less accurate as current goes down. I've therefore included Allegro Hall-effect current sensors that have some rather tight PCB requirements. (3) I've also included smaller current sensors for the brake coils, but don't plan on mounting them in hopes that the Roboteq battery current parameter will have enough resolution to detect coil faults. (4) To control seat lift and tilt actuators I've used SPDT automotive relays in H-bridge, self-braking configuration. Both physical limit switches and current drain monitoring will be used to detect end-of-travel and alter chair speed for less-stable CG conditions. If more than two actuators are wanted, another relay board would have to be added. (5) the contactor and actuator relays have snubber resistors rather than diodes to avoid compromising contact break time, (the Roboteq digital outputs are 1 Amp continuous low-side MOSFETS) (6) For LED lights, I've chosen STM Pentawatt-V power switches that provide control of moderate currents without needing added components. (7) The circuits are sprinkled with transient voltage suppressors - I hope enough of them and with the right specs.
To do: An RTC has to be added for time-stamping the log file. I have a DS3231 board on order, but fear that it's been caught in the Hong Kong and China post decision to X-ray everything and send anything that might contain a Li cell back to the sender. We'll see.
I have to get an accelerometer to add to the Aux node and port the code I now have running in a free-standing Uno on Rachi's chair to provide shock/stability sensing. This, along with the actuator limit switches/current monitoring will trigger the Stop, VerySlow, Slow and full-speed states of SpeedSlow already included in the sketches.
I have to place orders for boards and components. I've not found a single supplier who stocks everything, but between Mouser, Digikey, RS, Farnell (possibly) and e-bay I think I have a BOM. e.g. RS.it (but not RS.uk) has a good price for the contactor, IF I'd buy a minimum of 25 of them, so I paid a higher unit price to Mouser to buy one rather than 25, but Mouser doesn't stock decent joysticks.
One thing still not decided is connectors. For the breadboard, I've just used the usual male & female headers, but on the deployed version I intend to connect the small stacked boards with male headers only, soldered to the boards. For the few off-board connections (joystick, CAN, 24V) I'll use some robust Molex variant (and add a dab of Goop to each; from experience a useful backup). Higher current connections will be ring terminals, Anderson SB50, power-pole and XT connectors as appropriate.
Schematics, pcb and program files are in the two zipped attachments.