Affordable, precise, integrated motion control for robotics
Let me start this log by wishing everyone good health in these extraordinary times. The COVID-19 pandemic has imposed strict rules that we are mostly unaccustomed to, however it is crucial that we remain patient and not deviate from our individual responsibilities in preventing further spread of the virus.
With most regions in China already recovering from the health crisis, PCB manufacturers are now able to undertake orders with a predictable time schedule, albeit inevitably with some delay. Having this in mind, I am happy to inform that I have sent the latest Tinymovr design, R3, to the PCB manufacturer as of yesterday. The boards are expected end of April/early May.
The R3 has several changes from the previous revision, featuring a Qorvo PAC5527 MCU, a MPS MA702 magnetic angle sensor, high quality TDK ceramic caps, compact DF13 connectors all over and holes for mounting XT30UPB power connector. Also, the pads for the motor leads are wider than in the previous release.
In addition to the above, I'm happy to report that the two remaining Tinymovr R2.1 boards in my possession are now integrated in the robotic leg that I mentioned in the previous log. Apart from some rotor synchronization issues arising from encoder limitations (outlined in previous posts), the leg seems to have no issue lifting 670g, with a maximum armature current of 8A:
Stay tuned for the next update!
The ongoing health crisis in China has affected PCB production and induced significant delays in PCB manufacturing and assembly. PCBWay, the manufacturer of Tinymovr prototypes, has announed delays of up to 30 days for small batch prototype runs. This is in addition to potential delays in shipping that are likely to be encountered.
Even though design of Tinymovr R3 is complete and has been carefully reviewed, I've decided to postpone sending the board to be manufactured until things settle down a bit and regular schedule is restored. This should incur a delay of about a month or so, which, in addition to a month between submitting design to receiving prototypes, should place the next round of Tinymovr boards in my hands late April 2020.
Taking advantage of this intermission, I've been working on a few improvements on the comms-side of Tinymovr, implementing a better CAN-Bus protocol that allows dynamic endpoint maps much like ODrive does. This goes in hand with an application I've been developing for interfacing and configuring Tinymovr from a PC/Mac, Tinymovr Studio.
As soon as I achieve some progress in this, I'm planning a robotics demo as a follow up to demonstrate application of Tinymovr. The demo will feature a 2DOF robot leg that uses Tinymovr R2 in both DOFs, with daisy-chained power and comms.
Here's a preview of the mechanical assembly, which is almost ready:
This is a dual-belt-in-series arrangement that is heavily influenced by the Solo quadruped robot of the Open Dynamic Robot Initiative. The belt transmission achieves a 1:10 reduction in a compact package that fits well to the elongated form of the leg itself. The plan is to have Tinymovr R3 integrated in the leg assembly, right opposite the motor, where the encoder magnet is found. The first order of things is to get some simple kinematics working, and following that maybe try to implement some dynamic movements such as jumping.
Stay tuned for more updates!
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:
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:
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...Read more »
Tinymovr r2 PCBs have recently arrived from China. In the meantime I've been improving the firmware, and at the present motor control (position, velocity and current) as well as CAN Bus and UART connectivity are fully functional.
Below is Tinymovr R2 next to a one Euro coin and a 4108 motor for size comparison.
New motor testing bed with UART, CAN Bus connections and oscilloscope probes.
As mentioned previously, this board revision replaces the AS5047 encoder for the MA730, which comes at a significantly lower cost. In addition, the power stage includes larger shunt resistors and 2oz copper traces, allowing a max calculated current of 30A continuous (with proper mosfet cooling).
Stay tuned for more videos of the board in action!
The design of Tinymovr r2 is complete. The board measures 40x40mm, that is 4mm less than r1 on each side. It also features a new magnetic angle sensor, MA730 by Monolithic Power Systems (MPS), which is lower cost than the AM5047/AM5048, and therefore further pushes down the cost of the driver.
The new board also features beefier shunt resistors which allows it to handle bigger currents.
Here below is a preview rendered using Fusion360. Not all components 3D models are available, so some are not visualized.
Boards will be arriving early January, and I'll be reporting on initial testing shortly after.
I've just completed the first implementation of CAN Bus for Tinymovr. A basic set of instructions is implemented so far, but more to follow.
In the tests below Tinymovr achieved a command rate of 500Hz for velocity and position commands, which is satisfactory for high-resolution control.
The video below was captured some time ago and shows initial testing of position control mode