Gyroscope
The control board is centered one of Analog Devices' highest rate gyro, the ADXRS649, rated for 20000 degrees per second but extendible to 50000 degrees per second, or around 8000 RPM. We chose the gyroscope as opposed to Open Melt's accelerometer method to avoid noise issues. While accelerometers will pick up any and all vibrations, gyroscopes are quite a bit more noise resistant. This is offset by the difficulty of finding a gyro with a large enough range and having to place the gyro at the exact center of rotation, since applying acceleration to a gyroscope causes error. Otherwise, all the other challenges are there, such as keeping the sensor in a constant position and orientation as the robot spins around and smashes things.
Analog to Digital Converter (ADC)
The gyroscope outputs a 5V analog signal, with zero rotation at 2.5V. This works out to 50 uV per degree, ideally. Our gyroscope ended up with a range of around 65000 degrees per second due to some curious part choices, making it 38 uV per degree. Thus, we needed accuracy in converting the analog to a digital signal. We used a 24-bit, 14 kSPS ADC from TI, the ADS1259.
Microcontroller
The ADC feeds into the STM32F405RGT6, an ARM Cortex-M4 32 bit microcontroller. The microcontroller was provided from Newark, a pretty good place to get parts. Why this microcontroller?
What stands out is this is an extremely high power chip without being weird. First thing we noticed is how little physical space it needs. It uses a standard 3.3 volt input, avoiding a separate 1.7 volt supply. There's no external RAM or even an oscillator required. All it needed was power. Instead of using the giant 20 pin ARM JTAG nonsense, it uses just 4 wires. On a space limited board such as Gyro King's, every square millimeter counts. And in return we got a 168 MHz processor with a floating point unit, allowing us to avoid the performance vs. fixed point tradeoff, extremely powerful timers, which was used in a previous project to control two three-phase motors with center-aligned PWM, dead time, and ADC triggers, and DMA on many peripherals to save your cycles and automate data capture. Notably, it has a completely free toolchain for compiling programs. Although difficult to set up on OSX, it is possible and certainly usable. Finally, this STM32 is RTOS (Real Time Operating System) friendly. We used the open source ChibiOS. This let us use higher level programming, such as multiple threads, and abstracted a lot of the lower level access. All things considered, a solid microcontroller.
Three Phase Motor Control and Drive
While it is entirely possible to generate the drive motors' three phase commutation signals and sense the rotor position directly from the microcontroller, we were pressed on time and feeling a bit lazy. We turned to Allegro MicroSystems' A4960 Automotive Sensorless BLDC controller. These chips perform sensorless commutation, start up, directly drive the motor MOSFETS, and current limiting all from some configuration from the microcontroller and a PWM signal. Using these significantly reduced development time, though we still have to tune all the parameters of commutation, such as dead time, zero crossing window, phase advance, and commutation blank time.
The Allegro controllers directly connect to a trio of half bridges composed of the IRFH5301TR1PBF N-channel MOSFETS, rated for 35A at 30V.
Board Layout and other Doodads
Connectivity was handled by a little Bluetooth doodad, the Roving Networks RN41-I/RM board. It was directly soldered on to the control board. It connected to a laptop running a pygame based GUI displaying things like spin speed, power, and direction. The controller is a PS3 controller.
The control board also had some good ideas, like a few status LEDs and what looks like a bar of ceramic bus capacitors, since electrolytics would not fit height-wise. A digital Hall-effect sensor was also on there to be used for calibration. Ideally, it would function as an on-board tachometer to a magnet held above it, providing an absolute reference for the rate of rotation, but was never implemented in software.
The board used four layers, to provide full ground planes to try to separate the combination of sensitive analog, digital, power regulation, and motor control on a tiny single board.
A notable bad idea was using test pads as the programming header. Due to space limitations we couldn't fit a full through hole header, so we used surface mount test pads. Of course they ripped out.
Conclusion
This was a pretty solid control board, surviving the impacts of robot battle while tracking well enough to provide a near constant direction at speeds up to 2000 RPM, the max we've seen it spin at. The component choices were all well made. We wouldn't use test pads as headers again though. Xo would go on to make a variation of this board with one brushless driver and two brushed drivers, but otherwise similar hardware.
I should also take pictures next time too.
