I've just finished testing a bunch of Tinymovr R2.1 boards, and results look promising, save for a few issues I have discovered along the way. 

The following functional aspects are fully tested and working in this latest revision:

• 3-phase PWM MOSFET driving at 20kHz
• Current sensing ADC for all three phases
• MA730 absolute encoder readings over SPI at 1MHz, encoder observer with velocity output
• Motor control loop at 10kHz (position, velocity, current control, position limiting, current limiting, velocity-dependent current limiting)
• Calibration of resistance, inductance and absolute encoder offset
• Overcurrent protection, undervoltage protection
• UART communication with simple protocol for configuration
• CAN Bus communication with comprehensive protocol and error handling. Bidirectional messaging tested up to 1kHz, @ 500kHz CAN bus speed.
• Basic configuration saving and loading to/from NVRam

In the following video, CAN bus at 500kHz is used for bidirectional communication. Initially,  the arduino issues a calibration command and checks if successful. Then, it sends a series of position commands at random intervals, and also requests position and velocity information at a rate of 500Hz, which is then retransmitted via Arduino serial and plotted using Serialplotter.

I’m planning a demo of a fully integrated (motor+controller) 2DoF robot leg, which will use 2x daisy-chained Tinymovr boards. More on that in future updates.

During my testing I’ve encountered a series of issues, briefly outlined below:

The first issue is with the encoder. This document by MPS describes an aspect of the MagAlpha encoder series that I have overlooked. In a nutshell, MagAlpha series encoders include a digital filter that introduces a tradeoff between encoder resolution and bandwidth. The MA730 used in Tinymovr has a high time-constant filter that allows for a 14-bit resolution but limits the bandwidth to 23Hz, according to the above document. In high acceleration scenarios, this makes the reported position lag behind significantly. Since the electrical angle is computed from the encoder, this also affects motor efficiency, and in some cases even throws the control loop out of whack. 

In the video above, you may notice some oscillations around the velocity setpoint, which are more profound in higher velocities. I have pinpointed this to be caused by the combination of motor cogging torque and encoder filter time-constant.

To mitigate such issues in the next revision, I’ll be using a lower 12-bit encoder, the MA702, which however has shorter time-constant filter that allows a reported 400Hz bandwidth. This should be sufficient for all but the most demanding acceleration scenarios. 

Another issue is with the power stage. It seems I miscalculated the values of the resistors that control slew rate and the board suffers from significant ringing during switching. Ringing is clearly visible in the oscilloscope, especially during switching at zero torque.

Even though it would be straightforward to just replace the resistors, I’ve decided a more radical change for the next revision that will hopefully bring more benefits. Qorvo recently released PAC5527, an MCU that is much like the PAC5523, however it has many of the external components found at the power stage embedded in the die. PAC5527 has a software adjustable slew rate and can work with input voltages of up to 48V.

Replacing the PAC5523 with the PAC5527 would bring several benefits to Tinymovr, the most important of which are:

• Higher rated input voltage range (48V up from the current 20V)
• Easier configuration of power stage parameters
• Reduced component count, which translates to more flexible board layout.

The higher rated voltage will also warrant changes to several passives, but also to the FETs which are currently rated for 30V.

While the above seem to require fundamental design changes, the fact is that all replacement parts are pin-compatible with existing ones, save for the inverter pins of the PAC5527. This means that the only part of the board to be redesigned will involve the gate driver traces, however this will be much simpler compared to the current power stage which includes much more passives as well as actives.

I’ll be updating this blog with progress on the next board revision, so stay tuned!