• Project state & next steps

    Yannis08/24/2020 at 19:35 0 comments

    It's been some time since the last update however the project has been moving on at rapid pace. First, the alpha boards and dev kits have been completed and sent out to their owners in early August. In addition, the Tinymovr Github repository now hosts the complete array of Tinymovr modules: Firmware, client (Studio), documentation and some related schematics and drawings. Furthermore, I've set up a Discord server to stir up the discussion. Hey! There's not much there yet, but given time.. :)

    Most importantly, the new batch (I call it alpha2, for lack of a better name) is in the works. There is no clear timeline yet, but I've been really busy with minor improvements in the PCB layout and planning production (hint: it will be outsourced this time). As part of this, I've recently received a bunch of 5005 motors from MAD Components, which will make it into the next Dev Kits:

    They are larger in diameter compared to the T-Motor 4004 shipped with the alpha, which means that Tinymovr will be able to be completely integrated behind the motor face, good news for building integrated servo drives :).

    That's all for now, stay safe and stay tuned for more updates!

  • Tinymovr alpha: Production Update #3

    Yannis08/01/2020 at 18:37 0 comments

    Production of Tinymovr boards and dev kits is almost complete! Here is a photo of most of them (a few are still getting connectors fitted):

    It took quite a sprint during the past few days but the alpha batch is now almost ready for shipment. This includes the boards themselves, Dev Kit motor holders, CAN bus adapters (CANdapters) and associated wires. 

    I'll be finalizing the boards today, and tomorrow I’ll be testing all boards and kits for a final time before packaging them. The aim is to ship on the 5th of August.

    Once the alpha boards/kits are on their way, I’ll be focusing on releasing the Tinymovr Firmware and creating a Discord server for support and discussion. I’ll be posting here with updates.

    Today I’m releasing the schematic of the CANdapter, the CAN adapter that is included with the Dev Kits, which is an adaptation of the CANable boards. You can find them in the Tinymovr Github repo.

    Once again, I’d like to thank all Tinymovr alpha participants for their support! I hope that you will enjoy your boards and use them in creating awesome robots!

  • Tinymovr alpha: Production Update #2

    Yannis07/26/2020 at 17:37 0 comments

    Here's a short update featuring a video that demonstrates the Tinymovr alpha Dev Kit in action:

    Torque tests go up to 10A due to absence of a good ventilation system, but extrapolated you should be able to reach around 0.6Nm at 30A.

    I've open sourced the STL files for the Dev Kit motor mount so you are welcome to build one yourself (you'll still need a CAN adapter and associated data and power cables though). 

    Tinymovr alpha is now closed. Thanks to everyone that participated! Boards and Dev Kits will be shipping soon.

    There will be a new round of boards/kits in the near future, so stay tuned!

  • Tinymovr alpha: Production Update #1

    Yannis07/22/2020 at 18:12 0 comments

    Here is the first update on the Tinymovr alpha board and Dev Kit manufacturing progress.

    I have received all R3.2 PCBs from the manufacturer. Around half of the received boards are assembled and tested, and they perform as expected. For the rest I am waiting for components to be delivered, expected towards the end of the coming week.

    In addition, I’ve completed design, assembly and testing of the first Dev Kit (image below).

    The rest of the kits will be assembled in the coming week. In the meanwhile, I’ll be posting a video on the Dev Kit operation soon.

    For the Dev Kits I have designed a lightweight mount that allows air circulation and that can be secured on a flat surface by adhesive or bolts. The mount allows access to all of the board’s ports while protecting the more sensitive polymer capacitors on the rear side. It is noted that in this configuration the encoder magnet is on the rear side of the board. This places tighter tolerances on the distance of the magnet from the board, but the magnetic field is within the allowed tolerances by the encoder manufacturer. 

    Tinymovr Dev Kits include a USB-CAN Bus adapter board. This is an adaptation of the CANable design to use DF13 connectors as well as 2.54mm headers, and utilize a sturdier USB micro connector. This design will be open sourced in the spirit of the original CANable board. 

    For this board, PCBWay kindly offered a sponsorship, and the boards just arrived today. They are beautiful in black matte soldermask and ENIG plating (image below).

    Stay tuned as I’ll be posting a more in detail review of the boards in a few days.

    Regarding the boards themselves; Qorvo, the manufacturer of the PAC5527 chip, have recently released a bootloader that allows firmware upgrades through serial. This is a great solution to enable user-upgradeable firmware as the PAC is currently only supported by J-Link adapters, which, while very capable, carry quite the price tag. I’m working to have the alpha boards and dev kits bootloader-enabled before shipping. I’ve already integrated the bootloader into the Tinymovr project and tested it on one board, which seems to be working as expected. More tests to follow.

    Finally, today I’m open-sourcing the first of the Tinymovr software components, the Tinymovr Studio. Tinymovr Studio is a cross-platform (Windows, Macos, Linux) Python library and command line app that takes care of communication with Tinymovr using CAN bus. The user can type in commands in an IPython prompt to send/receive messages, or integrate the library to their project and take advantage of the simple API. Tinymovr Studio will be available through PyPI once Tinymovr alpha is sent out to users. Tinymovr Studio uses the python-can library, allowing it to interface with a broad array of hardware interfaces (including CANable through slcan). In the workshop I’m using it with an Arduino and MCP2551 based adapter I cobbled together for testing. 

    The Tinymovr Studio repository also includes work-in-progress project documentation.

    Head over to the Tinymovr github repository for more.

    Stay tuned for more updates and releases in the coming days.

  • Tinymovr alpha Available to Order

    Yannis07/06/2020 at 20:35 0 comments

    Tinymovr is entering alpha testing phase, and you are invited to participate! Sign up below to get a super-early bird Tinymovr R3.2 Board or Dev Kit:

    https://forms.gle/omLXWxJpDSP388qm6

    Tech specs:

    • 3-phase brushless motor controller with Field Oriented Control
    • Input Voltage: 12 - 26V, XT30UPB connector, 35A continuous phase current
    • PAC5527 Integrated MCU+Gate Driver (150MHz Cortex-M4F w/ 128k flash, 32k RAM)
    • MA702 absolute position magnetic encoder with 12.5 bit resolution
    • FDMD8530 mosfets, 30V 1.25mΩ max. rDS(on), mosfets rated for 127A continuous
    • CAN bus and serial (TTL) connectivity, SWD header for debugging and flashing firmware.
    • 20kHz switching and control frequency
    • Board Dimensions: 40mm x 42mm x 10mm(approx height)

    The price of the alpha boards will be $39/39€, plus shipping costs (includes Tinymovr, diametrically-magnetized magnet and 1x DF-13 to female header cable). You will need your own means of talking CAN with the controller, a 3-phase brushless motor, a way of securing the magnet on the motor axis and Tinymovr on the motor, and a 12-26V power source.

    There are also dev kits available for $119/119€, plus shipping costs. Dev kits include Tinymovr + diametrically magnetized magnet + high quality T-Motor 4004 motor integrated in a compact stand, a Canable-compatible CAN Adapter and assorted power and signal cables and wires. You'll need a micro USB cable and a 12-26V power source.

    Alpha users will receive individual support in setting up Tinymovr for their projects.

    Please note that currently the amount of Tinymovr boards/dev kits is limited to one per person. In later batches it will be possible to purchase more boards.

    Tinymovr ships from the EU to addresses in Australia, Canada, the EU, UK or US.

    Estimated shipping is beginning of August 2020.

    Have fun building awesome robots!

  • Production updates, availability, open source etc.

    Yannis07/02/2020 at 21:54 0 comments

    There are a lot of important news to share :). Here they are in no particular order:

    1. I’m currently making an attempt at moving PCB assembly of the first Tinymovr batches in house. For those new to the project, assembly of previous batches was outsourced to Chinese manufacturers. While this is a safe and painless option, it is becoming increasingly challenging to realize the vision of Tinymovr as a low-cost but fully-featured servo motor controller, due to import taxes and customs fees. At the same time, PCB assembly prices in EU are sky high. Therefore, I decided to move assembly of the first prototype batches in house. Got the first PCBs from Aisler a few days ago and built two prototype boards. The boards have been tested with phase currents up to 20A and angular velocities up to 300000CPR/s (around 2100 rpm). I’ll be building a few more in the next days, at the same time trying to optimize assembly. I am so far confident that this is a viable option. I’ll reconsider outsourcing production if and when production scales to justifiable numbers.

    Here below the first home-grown Tinymovr :) :

    2. The CAN Bus transceiver swap outlined in previous posts has been a success. It has vastly improved connection reliability, and reduced MCU power draw (since it is powered directly from VBus) and thermal performance.

    3. There are questions regarding open sourcing of PCB schematics/drawings and firmware, so I think it’s time to clear things up for everyone:

    • Tinymovr drawings and schematics will NOT be open sourced or available for purchase. Maybe in the future. Not right now.
    • The firmware WILL BE open source, licensed under the GPL v3. There are still things to sort out in the firmware before releasing but I expect that by the end of July the it will be available in Github.

    4. There are also questions regarding availability of Tinymovr. If the in-house assembly experiment goes as planned, my goal is to have a limited alpha run beginning in the next 2-3 weeks. I’ll probably include options to order just the Tinymovr boards as well as dev kits that will include motor, CAN Bus adapter and programmer (most probably a J-Link EDU Mini). The alpha boards and kits will be distributed at a price near the cost of the board, components and materials. This means that the price of alpha boards/kits will be lower than the price of production Tinymovr, when released. The boards and kits will be thoroughly tested before being sent out. 

    5. I’ve been doing some performance validation mainly looking at switching transients and ripple current. Below I attach the relevant scope shots. 

    Below is seen around 3V overshoot on the rising edge and 5V on the falling.

    In the grab below there is a 200mV ripple at 18A phase current, using 3x 68uF 30mOhm ESR polymer capacitors. 

    6. I've complete the quadruped robot based on Tinymovr R3.1 boards. I'm glad to report that, using the 3D printed actuators the motor phase current is less than 2A at stance. Here a short video below:

    I’m really excited to be reaching an important milestone in this journey, roughly a year and a half after my first design attempts at Tinymovr. I hope this project will be able to foster a strong community and ultimately make creating awesome robots easy and affordable!

  • Firmware improvements - CAN Protocol, Improving Position Tracking

    Yannis06/13/2020 at 20:06 0 comments

    In the last post I covered improvements in the hardware side of Tinymovr R3.1 that resulted in a minor revision R3.2. This post will go over improvements on the Tinymovr firmware performed in the past couple months. 

    CAN Bus Protocol

    Implementation of CAN communication is now complete, and Tinymovr is fully operable through CAN. In the protocol I designed I’ve decided to stay as close as possible to the CANSimple protocol, adopted by the ODrive community, for compatibility reasons. Of course, it was not possible to fully conform to that protocol, as there are differences in hardware and features. However, in the approach I've taken I've tried to match the functionality of critical CAN commands (such as setting of states, setpoints and parameters). In addition, in order to stay compatible I've tried to extend the message content of some commands, instead of replacing; for instance, the State endpoint (0x03) returns an array that contains the error as a first element but also the controller state and control mode. If you are interested in the error only, you can just grab the first item in the returned tuple. 

    Below is a table with the commands (endpoints) in more detail:

    EndpointAddressTypeValues
    Byte Offset
    Estop0x02W----
    State0x03RError (uint8)
    State (uint8)
    Ctrl Mode (uint8)
    0
    1
    2
    CAN Config0x05RCAN ID (uint8)
    kbaud Rate (uint16)
    0
    1
    Set CAN Config0x06WCAN ID (uint8)
    kbaud Rate (uint16)
    0
    1
    Set State0x07WState (uint8)
    Control Mode (uint8)
    0
    1
    Encoder Estimates0x09RPosition Estimate(float)
    Velocity Estimate(float)
    0
    4
    Set Position Setpoint0x0CWPosition Setpoint (float)
    Velocity FF (int16)
    Current FF (int16
    0
    4
    6
    Set Velocity Setpoint0x0DWVelocity Setpoint (float)
    Current FF (float)
    0
    4
    Set Current Setpoint0x0EWCurrent Setpoint (float)0
    Set Limits0x0FWVelocity Limit (float)
    Current Limit (float)
    0
    4
    Iq Estimate and Setpoint0x14RIq Estimate (float)
    Iq Setpoint (float)
    0
    4
    Limits0x15RVelocity Limit (float)
    0
    4
    Reset0x16W----
    Vbus0x17RBus Voltage (float)0
    Position and Velocity Gains0x18RPosition Gain (float)
    Velocity Gain (float)
    0
    4
    Set Position and Velocity Gains0x19WPosition Gain (float)
    Velocity Gain (float)
    0
    4
    Device Info0x1ARDevice info register (uint32)0
    MCU Cycle Timings0x1BRBusy Cycles (uint16)
    Total Cycles (uint16)
    0
    2
    Save Config0x1CW----
    Erase Config0x1DW----
    Motor Info0x1ERMotor Calibrated (uint8)
    Motor R (uint16)
    Motor Pole Pairs (uint8)
    Motor L (float)
    0
    1
    3
    4

    The endpoints that are read (R) work by the client sending a request to transmit (RTR) and Tinymovr sending back the corresponding message. Note that this is an early protocol draft, and subject to change.

    Position Tracking Improvements

    The encoder/observer infrastructure has been vastly improved as well. Here, I’ve been dealing with the problem of diminishing floating point accuracy as the position setpoints reach large values, due to the limited 23-bit significand of single precision floats. This is an issue that has come up from time to time in various message boards, but afaik no concrete solution is available up till now.

    To address this issue, there are two sub-problems that need to be addressed: The first problem concerns the estimation of the rotor angle in order to derive electrical angle and ensure accurate commutation. This is easily achieved by using a separate angle estimate that is wrapped to [0, 2pi). The second problem is a bit more complex and entails accurately tracking the rotor position value on the position axis. The issue here is that at large values the estimate of rotor position is increasingly quantized, due to the rapidly diminishing accuracy of floating point representation. Consider as an example the value 5000000 (5*10^6), which is a representable number in IEEE 754 single-precision floating point variable format. The next representable number, is 5000000.5. This is barely adequate to represent the observer rotor position estimate, and it only gets worse as the values increase. In tests that I did at such rotor positions, the effect due to quantization is that the velocity...

    Read more »

  • Dealing with (and fixing) an unexpected glitch

    Yannis05/31/2020 at 12:23 0 comments

    In this post I wanted to focus on Tinymovr firmware improvements and plan out the next steps, however an unexpected glitch had me spending all my development time on it and thus the rest of the updates have been pushed back a bit.

    Last week I put together a “torture test” for Tinymovr with the aim of testing several aspects such as position tracking, torque generation, commutation in higher angular velocities, communication etc. The test consisted of reading encoder estimates and commanding random position increments ranging from 0 to 2π (0 to 8192 encoder ticks) at random intervals ranging from 5ms to 100ms.

    During the test I’ve noticed that in some cases the motor jumps around at velocity limit, and towards positions far beyond commanded ones. Monitoring the CAN traffic I found that some messages sent by Tinymovr contain garbage position values. They are not frequent (on average one in 5000), but they are certainly deal-breakers for high-frequency communication. Moreover, the issue only affected messages sent by Tinymovr, the ones received were always pristine. 

    Long story short, after discovering this I engaged in a week-long investigation to find the root cause. CAN having strong error detection and all, it is unlikely that this error originates in the bus itself. I thus focused on the parts before and after the bus. I quickly dismissed the receiver side (consisting of an Arduino and a MCP2515 breakout, connected through short, shielded wiring) after successfully testing it with another CAN device. In addition, I knew that with the exact same setup and the previous Tinymovr R2 boards there were no errors in communication at all. Therefore I focused on Tinymovr itself.

    One thing I did notice was that the PAC5527 controller itself was relatively warm to the touch. Not so much that it would burn your hands but it would be uncomfortable to the touch after a few seconds. Disabling all peripherals and setting the MCU to sleep mode revealed a 30mA current draw at 12V.  The PAC5527 on Tinymovr powers two external devices and a led through its VSYS LDO: the led draws 5mA, the magnetic encoder is supposed to draw 12mA at 3.3V and the CAN transceiver is supposed to draw 10mA at 5V at recessive state, but also a whopping 40mA when setting the line to dominant state! This is of course reasonable if one remembers that CAN has 120Ohm termination resistors and a 5V potential difference between high and low states when bus dominant, which gives a minimum current draw of 5/120 ~= 0.04, but it was something that admittedly I did not consider in design.

    Taking a look at the datasheet, the VSYS LDO mentions a max external load of 50mA at 5V, which is higher than the combined 27mA when recessive, but not higher than the combined 57mA when dominant! It is therefore possible that the excessive current required during CAN bus transmission introduces voltage drops that in turn cause memory or I/O related issues, as well as excessive heat due to the stress on the LDOs. At last, we have a plausible scenario! :) 

    This also corroborates with the observation that the previous R2 boards running without errors, as, according to the PAC5523 dataset, the PAC5523 LDO can supply up to 330mA total, and excluding the 60mA max per internal LDO, there are 80mA left for external loads.

    In order to mitigate I took a few steps to minimize current draw as much as I could given the current design:

    1. Increase encoder SPI frequency as much as possible without introducing errors, to minimize the time spent by the processor in waiting encoder data. Currently it is set to 12.5MHz
    2. Increase CAN Bus frequency to 1MHz from 250kHz, to minimize the time the transceiver has to hold the line in the dominant state (and thus request more current). Admittedly this seems one of the few cases where *increasing* the baud rate results in less errors… :D
    3. Use large heatsinks where possible
    4. Remove the led! Currently the led consumes just...
    Read more »

  • Tinymovr R3

    Yannis05/21/2020 at 18:01 0 comments

    Tinymovr R3 boards have recently arrived from China and I've been busy testing and improving things all over. Bottom line, they perform very well so far!

    The new MA702 encoder really makes a difference as angular position tracking is now super responsive and able to handle even the most vigorous accelerations. Due to the improved dynamic tracking performance, commutation is also more efficient, as the electrical angle is tracked much more precisely. The advertised mean accuracy of 11.5bits is easily achieved and even surpassed with a NdFeB N35 magnet at around 1.5mm distance from the chip, and with the addition of a Luenberger observer I get an accurate (low noise) 13bit position estimation (8192 CPR).

    The new PAC5527 controller also makes a difference since it enables the input voltage to go up to 30V, limited by the power transistors (FDMD8530). I have tested the board up to 26V input and 15A phase current with reliable performance. More tests pending :) 

    For safety reasons, however Tinymovr will be rated to 24V. In addition, PAC5527 allows for software slew rate control, using which and after some experimenting I ended up with much better commutation with less ringing. 

    Tinymovr R3 has more capacitance than it's predecessor with 8x 10uF ceramic capacitors and 3x 4.7uF on the shunt resistor high side, however these will be replaced with a combination of ceramic and electrolytic in R3.1. R3 also features CAN Bus, UART and SWD connections, each of which is broken out to DF-13 connectors, however to manage compoment costs R3.1 will only break out CAN Bus to DF-13, while others will be available as through-holes on board. In addition, there are through holes sized to accommodate a XT-30UPB connector that can be mounted on either side of the board. 

    Here's the board mounted to the test stand together with a 4108 380kV motor:

    That’s it for now, but stay tuned for the next post very soon where I will discuss test results and firmware development, together with some good news :)

  • Tinymovr blog post, first R3 units soon delivered

    Yannis04/19/2020 at 19:33 0 comments

    Hi everyone, here's a short update on Tinymovr.

    I've posted a new blog post over at backyardrobotics blog, outlining the development of Tinymovr up till now, in a more informal manner.

    I've designed a new leg actuator for the quadruped robot that is more compact and completely encloses the electronics. Preview below:

    Finally, I received note from the PCB manufacturer that the new R3 boards are on their way. I do expect a delay given the circumstances, but let's hope for the best :)