• R3 Production Schedule, CAN Bus Improvements, Robotics Demo

    Yannis2 days ago 0 comments

    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!

  • R2.1 Testing and Next Revision

    Yannis01/28/2020 at 16:43 0 comments

    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...

    Read more »

  • R2 arrives, size comparison

    Yannis01/18/2020 at 15:42 0 comments

    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!

  • Tinymovr r2 design complete

    Yannis12/15/2019 at 10:14 0 comments

    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.

  • CAN Bus Testing

    Yannis12/02/2019 at 22:08 0 comments

    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.

  • Initial position mode testing

    Yannis11/26/2019 at 21:24 0 comments

    The video below was captured some time ago and shows initial testing of position control mode