EnsembleBot is not dead! It just smells funny. Progress has been rather slow, but some progress has been made, nevertheless.
FIRMWARE
There has been a lot of firmware re-coding of the instrument controllers. The CAN bus handling and the local bus buffering has been streamlined. This should make the firmware code across the EnsembleBot more homogenous, as well as preventing the nasty bottlenecks and buffer overflows, that used to plague the busses.
UPGRADED PERCUSSION CONTROLLER
The percussion controller manages both the tubular bells, glockenspiel and the miscellaneous percussion. In some music pieces, this instrument group can be very busy indeed, so to make sure we don’t exhaust the buffers and limited CPU time, we decided to upgrade the Arduino Mega (8-bit, 16MHz) controller to the almost pin-compatible but much more powerful Arduino Due (32-bit, 84 MHz ARM).
Now, while the Due is almost identical to the Mega regarding form factor and pin configuration, there are some important differences. Obviously, the Due is a strictly 3.3 V MCU, while the Mega is 5 V. Fortunately this poses no problems in our setup, which can easily work at 3.3 V levels.
But because I didn’t pay attention to the specifications of the Due, I didn’t realize that it hasn’t got an onboard EEPROM, like pretty much all other MCU development kits. Why is this a problem? I’ll come back to that in a moment.
On the plus side, besides more CPU power and SRAM, the Due boasts two I2C busses and an embedded CAN bus controller. Both of these features are of interest to us. The CAN controller allows us to use the good old SN65HVD230 3.3 V CAN transceiver, that we use in all the other parts of the EnsembleBot, and the CAN bus library for Due is much better than the old one, we used in the Mega.
BUILT-IN CALIBRATOR
While we are upgrading the hardware and the firmware of the instrument controller, we also enabled the use of MIDI velocity on all the percussive instruments to give some dynamic range to the instruments. All the instruments are based on linear solenoids, so it’s rather limited how much dynamic control we have, but some is better than nothing.
The only way to control the dynamics (or “volume”) of the bells and drums etc. is to adjust the actuation time of each solenoid. A short actuation means a softer stroke, and a longer actuation means a more powerful and louder stroke.
Each solenoid must be individually calibrated to determine it’s particular minimum and maximum actuation times. And what’s more, the calibration changes over time. Given that we currently use more than 50 solenoids, and more might be coming, it could easily become a quite annoying task to determine the calibration values, hardcode them into the firmware, upload the firmware and test. Repeat ad nauseam.
So, to make this task easier, we built a dedicated calibration circuitry. This consists of a small OLED display, 4 pushbuttons and an I2C EEPROM module (because the Due hasn’t got one, but it does have a secondary I2C bus which we can now dedicate to the EEPROM module and OLED display). During MCU boot-up, one can enter the calibration mode, browse through the registered solenoids, change the minimum and maximum values and test them on the spot. All changed values are saved to the EEPROM, containing all current calibration values.
What would have taken me days to do before, can now be done in less than half an hour, and with no need for firmware changes or even the use of a computer.