Affordable, precise, integrated motion control for robotics
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
We are now publishing our updates over at the official Tinymovr blog. See you there!
We're glad to report that our CANine USB-to-CAN adapters are back in stock! We've updated the CANine adapter, which is now fully compatible with USB-C cables. To address the semiconductor shortage, we exchanged a few components on the board for more readily available ones; some of the shipped boards will include these new components. In any case, all newly shipped CANine boards are functionally identical.
Up until now, Tinymovr development was carried out using the Qorvo-supplied, Eclipse-based development environment. While this solution supports all necessary functionalities, it comes with a few drawbacks. The most important is that it is only supported on Windows, so our Linux or MacOS-based users may have a hard time adapting the firmware to their needs. To improve this we set out on an effort to create a build and debug environment to allow users to build and debug the Tinymovr firmware using GNU make. As a result of this, you can now clone the Tinymovr repo in any arm-embedded-gcc supported OS and build the firmware with a single make command. What’s more, we included configurations for VS Code Makefile tools and Cortex-debug, to enable building and debugging right from within VSCode!
Here's a VSCode screenshot during a debug session:
To experiment with the new setup you will need VSCode, a J-Link probe, and the latest Tinymovr firmware source from Github. More info can be found in the docs. While we were at it, we cleaned up a few issues and did some minor refactoring to simplify the code and make it more readable. If you are interested in a slightly more performant firmware, take a look at the releases.
On another note, we published an introduction video outlining the effects of inrush current on electronics, and how our PDB Dianome helps protect from it. Check it out below:
With the new year's upon us we'd like to take this chance to thank all of our users who have supported us through 2021, and helped improve our products through their feedback. We are working on numerous software and hardware updates for the coming period, and we'll be sharing more in future updates starting with the new year, so stay tuned!
Happy holidays, happy new year, and as always, stay safe!
We've released a new firmware that implements read-write CAN endpoints, which we call "one-shot" endpoints. Up till now, endpoints in Tinymovr were able to perform either read or write operations; for a write operation, studio transmitted a regular CAN frame asynchronously, while for a read operation, the client transmitted a RTR frame and awaited the response from the firmware. Thus, for a read-write operation, a total of three frames were required.
One-shot endpoints function as read endpoints, but instead of studio transmitting an RTR frame, it transmits a regular frame containing write data, and waits for a response with read data. Thus, for read-write operations the required number of frames is reduced from three to two. The new endpoints are documented here.
The new firmware is available immediately. Do not forget to update your Studio installation as well!
In addition, we have released Dianome (/ðʝanoˈmi/, from the Greek word διανομή, meaning "distribution"), a compact power distribution board with protection features. Dianome allow distribution from a single male XT-60 connector to six XT-30 female connectors. It has inrush current limiting, and as such can be used to drive large capacitive loads in the range of several 1000 μF. In addition, it has over- and under-voltage and short protection. It has a footprint of 32 x 32mm and standard hole spacing of 30,5 x 30,5mm.
Dianome is currently in beta, which means there will probably be rough edges and you will have to solder the connectors yourself. We are working on improving these aspects. On the up side, you get the board (and connectors if you choose) at a favorable pricing.
Till the next update!
We have a brand new batch of CANine USB-C to CAN Bus adapters in stock! The production of the CANine PCBs has been partially sponsored by PCBway, and the assembly is being performed in house!
As part of the sponsorship, PCBWay kindly asked us to provide a review of the PCBs. As it happens, our earlier CANine PCBs were also produced by PCBWay, and were reviewed last year. Thankfully one PCB from the last batch was still laying around somewhere in the workshop, so we thought it’d be cool to compare that batch to the new one!
One comment that we had on the previous batch is that the silkscreen was a bit blurry. We wanted to see if this has been improved in the new version, so our comparison focused there. We were glad to find that the silkscreen was much sharper this time, with even tiny markings of 0603 and 0402 components being legible.
The image below summarizes the differences.
On the top left, is last year’s batch, while on the bottom right is a PCB from the new batch. It was not possible to fully capture the difference with the camera, however in real life the improvement of the new batch is even more obvious.
Apart from the silkscreen improvements, the soldermask displays a beautiful black matte finish, and the outline of the board is cut to precision without any artifacts from the cutting process or panelization. In fact, we noticed that the cut is much cleaner in the new boards, with much less burr from the cutting process. Overall a fine result with no noticeable flaws.
As in the last time, the ordering process from PCBWay was smooth and the representatives were quick to respond to any questions. In our case the package was shipped with DHL and arrived a few days later.
For this batch we are experimenting with in-house production, using a new Pick and place machine, and so far we have good results. An assembled board is shown below:
The Tinymovr store is fully stocked and all items ship within 48h worldwide. Go ahead and browse our selection!
We've rewritten portions of the slcan firmware used in the CANine adapter to use pure USB comms via libusb. The new firmware ditches the Virtual-Com-Port (VCP) cruft that is the source of many issues, not the least of which is abysmal CAN communication performance on Windows. The new firmware is known as CANine-fw and is of course open source, as is the hardware.
Initial tests indicate that CANine-fw pushes performance compared to slcan. It is now possible to do a round-trip message in exactly 1ms, which is the polling time for USB full-speed. With slcan, this was around 1.5 - 2.0 ms for Linux ans Macos, and around 20ms for Windows!
The new firmware does come with a downside, in that now a libusb driver is needed on Windows and Macos. Nonetheless, driver installation is easy and documented.
The new firmware is currently in alpha, and installation is a bit involved. To upgrade your adapter, please follow the instructions in the documentation. To use CANine-fw you will need to upgrade to Tinymovr Studio v0.4, which means you will have to clone the github main branch and install using:
pip3 install -e .
This version of studio points to a forked version of python-can that incorporates the correct driver for CANine fw. We plan a pull request to the main python-can repo once the changes have been thoroughly tested.
The new firmware should be backwards compatible with CANable devices, although we did not yet perform any relevant tests.
In other news, we've created a new Github organization to better organize our robotics-related repos. Feel free to browse around!
We're already in holiday season in Greece, and this means that for a while our operations will be winding down to give us a chance for a much needed break! As such, orders placed will ship on the 13th of August. In addition, we expect new stock on all our major products by the 17th of August!
We wish you all fun and safe holidays, and see you in the next update in September!
Message from update author: I mistakenly forgot to publish this update and I just realized it now. Well, better late than never! Here it goes:
Presenting: The Tinymovr Trajectory Planner!
Video first:
We implemented a trapezoidal trajectory planner into Tinymovr, that runs at the 20kHz rate, for silky-smooth trajectory interpolation. The planner works in two modes: In acceleration-limited mode, you set the max acceleration and cruise velocity, and the planner derives the necessary travel times. In time-limited mode, you set the desired acceleration-cruise-deceleration times, and the planner derives the max acceleration, cruise speed, and deceleration values.
The planner is available through CAN Bus using the following commands:
tm1.plan_t_limit(target_pos, total_time, accel_percent, decel_percent)
The above command will initiate a time-limited trajectory with specified parameters. The accel_percent and decel_percent denote how much of the total move time will be taken by acceleration and deceleration. The scale here is 0-255, with 0-0% and 255-100%. This is a convenient mode if you wish to synchronize multiple axes of e.g. a cartesian machine. Alternatively, you can use a velocity and acceleration limited trajectory:
tm1.set_max_accel_decel(max_accel, max_decel)
tm1.plan_v_limit(target_pos, max_vel)
The above will generate a trajectory that respects the limits in acceleration, cruise velocity, and deceleration specified.
The velocity-limited trajectory planner is also available through the UART protocol, where you can specify parameters one at a time with different commands:
Max acceleration:
.>50000
Max deceleration:
.<50000
Max velocity:
.^100000
Plan and execute move to a position:
T-100000
We hope this functionality extends the applications of Tinymovr, and can't wait to see how you apply it!
We'll be switching to bi-monthly updates for the duration of the summer, and re-evaluate afterward. See you in the next update!
Welcome to another Tinymovr Update! Work on Tinymovr in the past month focused mainly on fixing various small issues, as well as improving performance and safety!
Sometimes breaking changes may occur in either firmware or client software. This is inevitable in the early stage of product development, but may occur even in the mature development stage. To ensure API compatibility, a mechanism to ensure compatibility between firmware and client side is necessary. Even more so in mission critical systems such as motion control, where API incompatibility may result in undesired behavior, property damage or even injury!
With this in mind Tinymovr is introducing a new system of compatibility “self-verification” for Tinymovr Firmware and Studio, starting from v0.8.7 and v0.3.7, respectively. The system is simple: The firmware holds, together with its own version, a flag that denotes the minimum supported Tinymovr Studio version. This can be obtained through a standard CAN Bus endpoint, and is also user-readable. In parallel, Studio has its own flag that denotes the minimum supported Firmware version. At Studio startup, two comparisons are made: min studio version requirement with actual studio version, and min firmware version requirement with actual firmware version. If one of them fails, Studio exits with an error message.
In this way, it is possible to manage compatibility separately for Firmware and Studio, and always ensure that versions working together are compatible. This also allows for the least number of upgrades to be performed by the user: If a new firmware upgrade is available that does not break API, the user can continue with the same version of Studio if they wish, and vice versa.
The second feature addition allows user-defined rotor zero-point and direction. It is now possible through Tinymovr studio (and CAN Bus API of course) to set a user-defined zero point for the rotor, also known as offset, as well as set the direction of the rotor to be either positive, i.e. electrical phase same as encoder, or negative, i.e. electrical phase opposite to encoder. The settings are persisted in Non-Volatile Memory.
Besides, several minor issues have been addressed, both in firmware as well as studio. Indicatively, writing to NVM has been simplified, better fault handler debugging features have been added, and the CAN Bus module in Tinymovr Studio has seen a cleanup and renaming to better distinguish it from the Python CAN module. All these changes may break some programs using the Tinymovr Python API, but overall disturbances should be minimal.
The latest firmware is available now and goes together with Tinymovr studio, which you can easily install with
pip3 install tinymovr
And since this month’s update is mostly text-text-text, here’s a Tinymovr-powered jumping robot video to cheer things up a bit! :
Till next month!
Welcome to another Tinymovr monthly update, with a lot of news to share. The Tinymovr store is now fully stocked with boards as well as dev kits and accessories. Dev kits include a Tinymovr R3.4 controller, a high-quality 5005 size motor from MAD Components, and a 6mm diametrically magnetized magnet securely mounted on the shaft.
The mount is made of precision CNC machined 6061 aluminum designed to be in contact with both stator and power MOSFETs, enhancing heat dissipation. Using the mount, you can turn the dev kit into a compact servomotor unit, fully integrated with your project. Or, you can use the kit standalone, using the provided 3D printed stand.
In addition, we introduced the ACT8.3 Open Source actuator, a lightweight module that achieves 1.7Nm@15A, while weighing a little over 200g (0.44 lbs). ACT8.3 is suitable for building legged robots, and soon a completely open source robot based on ACT8.3 will be published.
The firmware has seen important improvements as well. The most important being the introduction of encoder eccentricity calibration, which allows for more accurate positioning and smoother performance in high rotational velocities. See the video below for more information, and upgrade using the firmware in the latest release.
Finally, on the devops side, CI has seen vast improvements, with the firmware check and build pipeline getting a major overhaul.
For more details on related changes, check out the commit history.
See you next month!
I'm glad to report that the upgraded Tinymovr Dev Kit R2 is available in the Tinymovr store.
The new Dev Kit R2 is more compact, and can be used as an integrated servo actuator in your next robotics project! Simply detach the mount from the 3D printed stand using the two screws, and integrate it into your robot! Full 3D CAD drawings are available.
R2 has been upgraded from the ground up to include a new R3.4 Tinymovr, a MAD 5005 350Kv motor, and a precision CNC machined mount! The new R3.4 Tinymovr, included with the new Dev Kit, has an enhanced PCB layout for better heat dissipation, and better labeling of all headers onboard.
Back with another update in what seems to resemble a regular monthly update cycle :D
The big news is the release of the new Tinymovr R3.4, with immediate availability of boards in store. There is a temporary shortage of Dev Kits, but these should be restocked by the end of the month. Tinymovr R3.4 features some optimizations in power routing, allowing wider traces and better via interconnects between layers. Also, all IOs are now properly labeled, and a small geometry deviation with the board shape is fixed! So head over to the Tinymovr store to find out more!
Besides, this month’s update brings two important improvements to the Tinymovr firmware (0.8.4) as well as to Studio (0.3.4).
The first is support for gimbal motors out of the box. It is now possible to set the motor type to gimbal and specify resistance and inductance (those are not measured in gimbal mode, so to find them consult your motor datasheet), and continue with calibration as normal. The firmware will detect all other parameters except R and L as usual, and you will be able to use the motor in all control modes.
Here is a video of a gimbal motor driven by Tinymovr:
The second concerns an important fix to a bug in the scheduler that would sometimes permit “dead” control cycles, due to the MCU entering sleep state prematurely. This has been fixed and minor improvements were done to the scheduler as well.
Besides, minor improvements are to be found all around, from documentation to Tinymovr studio, testing, and CI. For more details, check out the commit history.
Finally, here are a few updates on projects using Tinymovr:
Till next month, stay safe and stay tuned!
Create an account to leave a comment. Already have an account? Log In.
It's because each MOSFET (FDMD8530) is dual channel. Basically, it can do the job of two MOSFETs in the package of one.
Exactly as @Gravis explained. These are FDMD8530, if you are looking for the part number.
Hi Yannis, are there any provisions for brake resistors, whats the strategy for dealing with large decelerating masses (e.g. CNC mill)?
Hi, I'm planning to implement flux braking at some point, which uses the coils of the motor itself as a resistor to dissipate power. Nonetheless, I'm not sure if Tinymovr is ideal for a spindle application, i.e. 10k+ RPM rotation speeds. For such an application one would typically use sensorless commutation, for which a regular ESC would suffice. As it stands Tinymovr has a hard RPM limit implemented at 4k RPM.
Is there already any code written so that this controller could be used as a brushed DC motor controller? For a haptic application, I am currently searching for open source dc motor controllers with current control capability.
Hi, there is currently no code for controlling brushed DC motors, although of course the hardware is perfectly capable.
Hi Yannis. I would like to know if it would be possible to use Tinymovr driver for a 24V brushless ebike motor or it would be too much power. Regards,
Hi Ivan, 24V is certainly within spec, but it also depends on the total power. Tinymovr has been tested up to 30A. With good cooling it should be ok.
How much power does your application require?
are these for sale somewhere? or is it still being tested in and going to be for sale in the future
H Justin, the alpha2 batch will be very soon for sale at tinymovr.com . You can sign up there to get an email notification once they are available.
Hey, I was wondering what kind of control you were using and how you implemented it - are you using FOC, Sinusoidal control? Thanks a lot :)
Hi, thanks, Tinymovr uses Field Oriented Control.
This is more or less the same as the mini-Cheetah controller... Why not to use the MIT project or branch it? What are the differences?
Hi, there are several differences; MCU, Driver, FETs, angle sensor.. all are different. Tinymovr uses integrated MCU+Driver vs discrete of Ben's design. Layout is 2 layer vs 4 layer. Also Tinymovr mainly uses 0603 for ease of hand assembly. Finally BOM cost is less.
Well, really the angle sensor are the same (MA700 and MA702), and I think the MCU chosen by Ben is more standard and with way better support.
But at the end, we are going to have two different projects so... better for everyone!
I will follow your progress and improvements. Nice project!
Great work! It is fun to see the steady progress. Keep it up!
Very impressive project! Do you have any plans to open source the firmware/EDA files once it is released? Also, do you have an idea of how much the boards will sell for?
Thank you for your comment. I'll be discussing these issues in the next update, soon.
Hi, our design is similar, I use PAC5523(PAC5527 voltage is too low)+MA702. My PCB is 5X5 cm. I also have CAN bus, do you use CAN OPEN?You're great!
Hi, great to hear about your project and please do share if it is public. Tinymovr will be using a protocol similar to Odrive's CANSimple for compatibility
Sorry for replying late, Hackaday has a really lousy notification system. Unfortunately the bandwidth of the MA730 filter at 23Hz is just too low for highly dynamic applications. Even mild accelerations throw the encoder off course and the commutation is all messed up, often leading to velocity runaway. MA702 has a much higher bandwidth close to 1kHz if I remember correctly, which is more than adequate.
hi Yannis I recently use this chip for develop too, do you manuly calibrate PAC5523 ADC ? I find the ADCOFFSET and ADCGAIN value in the INFO-2 register not correct.
Hi, I do a cycle-by-cycle offset correction, thus I do not use ADCOFFSET. Interesting though, I'll have to take a look at my ADCOFFSET values.
Thank you for your reply. I can read VREF/2 ADC output value to correction offet, and just use 2.5/4096 as the ADC gain but it seems to have some errors from the actual measurement. How do you solve the ADC gain problem?
I'm implementing current sensing very similar to ODrive, you can take a look here https://discourse.odriverobotics.com/t/the-motor-timing-diagram/219 maybe this addresses your question
Good luck and looking forward to seeing your project live :)
Great job. What is the motor you are using . Could you post a link ?
Could you post the current BOM? I'm curious which components you are using.
I've added the main components at the components section
OMG! You really do the great job! Oh I love it. The motor just run so so well! Very impressive!
I am planning to, yes. Stay tuned for updates.
Will this work with an external quadrature encoder? I'd like to play around with servos for x-y on a 3d printer and need the extra precision.
Not directly. You could handle the external loop yourself at the application level and send position or velocity commands to Tinymovr. But there is no provision for handling an additional encoder at this point.
Oh that looks exciting! No capacitors for the DC link voltage? I did not know the controller so far. Have you worked with it a lot already? Which mosfets did you use? For which performance is the board intended and what should it cost in the end? Many questions, I would be very happy about an answer - gladly also by PM. Greetings Ben
Hi Ben, caps are on the other side, not shown. Board is intended for small legged robots mainly, but should cover many light robotics tasks as well. Controller has it's quirks and documentation issues (which one doesn't?) but once some basic stuff is figured out its rather smooth sailing and you can focus on actual development. This prototype is 30A@20V but the next one should be able to do 30V. PM me for more info if you'd like.
Become a member to follow this project and never miss any updates
Maybe a stupid question, but why do I see only three MOSFETs instead of six? Very nice looking boards in any case.