jumper". This is a feature I need which other ESCs lack.
My bot will normally run autonomously in USB/ROS mode.
The bot will have a redundant minimal Arduino control system on I2C so the bot may always be relocated under power by a person walking alongside moving the joystick attached to the bot in the event of autonomous or RC failure. The Arduino will perform power off battery health and theft monitoring periodically waking and sleeping. It will continuously sanity check the ROS control outputs and abort autonomous control if some watchdog conditions are not timely met.
A human safety monitor will hold a RC transmitter to instantly take control in case autonomous goes off the rails or Arduino aborts in an unsafe place.
Therefore, it is important to switch between these 3 inputs predictably, via a wiring harness which splits the input select header to 3 independent systems and make sure reset occurs.
Perhaps custom firmware allowing input switch without reset is in order. For that matter, much of my arduino code could just be implemented inside near zero and additional IO via I2C expander chip https://www.ti.com/interface/i2c/genera ... ducts.html But that is not even half baked.
Which side of the jumper dictates the input select state? I'm sure the schematic would tell me but I did not see a .pdf version and my Chromebook cannot run KiCAD. From firmware, need to know which physical pins 26,27,28 are, and whatever logic enables ROS mode and PWM mode. CheckMode() seems to say all jumpers = ROS mode, no jumpers = PWM, but that doesn't match my intuition looking at the board silkscreen.
Code: Select all
const byte mode_reset = 28; //When this pin is grounded, USB input is selected. const byte mode_config = 27; //When this pin is grounded, I2C input is selected. const byte mode_i2c = 26; //When this pin is grounded, isp input is selected. pinMode(mode_reset, INPUT_PULLUP); pinMode(mode_i2c, INPUT_PULLUP); pinMode(mode_config, INPUT_PULLUP);
If PWM temporarily overrides I2C and/or USB, can control be seamlessly handed back? Autonomous will have to compensate for any motion that happened while it was out of control. I2C messages from Arduino might go unacknowledged or bus timed out while under PWM. Both I2C and USB should receive messages when their control is interrupted and returned so they can change program flow accordingly.