Thread Tools
Feb 21, 2017, 05:05 PM
Thread OP

T-STorM32: The best STorM32 ever !?


a thunder storm is on the horizon: T-STorM32, the best STorM32 ever !?

STorM32 goes encoder:

T-STorM32: The best STorM32 ever !? (4 min 21 sec)

T-STorM32 vs STorM32: Comparison of Current Consumption (1 min 37 sec)
Last edited by OlliW; Mar 28, 2019 at 08:25 AM.
Sign up now
to remove ads between posts
Feb 21, 2017, 05:05 PM
Thread OP

T-STorM32 releases

initial firmware:
18. Mar. 2017: alpha firmware version v2.26a released

v2.x NT motor module hardware:
9.3.2017: T-STorM32 NT motor module v2.4E released

eagle files are on github:

all info on the plugs&wires I'm using:

info on the ring magnets:


you may wonder why I have not released the firmware nor the NT motor module pcb.

Don't worry, I will, and the firmware will be free as usual.

I did not yet release the firmware since it's not finished, e.g., the GUI doesn't yet support all parameters, the NT logger doesn't record all data, there are likely some glitches I have not yet spotted, and so on. So, since anyone who would be interested in testing it would have to first build motor modules and a gimbal, I figured that any real request is still weeks away, giving me time to further work on the codes.

As regards the motor modules I'm not totally sure what to do. For one, I'm not totally happy with the hardware. I e.g. wonder if instead of the 6-pin 1 mm plugs I should not have better used 5-pin 1.25 mm plugs, and I do not like the fact that the DRV8313 motor drivers don't work with 2S. Also the STorM32 v2.4 board gets quite hot, since with that many NT modules on the 5V line the LDO has a hard time. I must admit that I'm jealous at the Basecam Tiny revB ... this is really designed by experts who know what they do ... way beyond my capabilties. Anyhow, that's the state of affairs, and hence I'm hesitant to release.

HOWEVER, I would of course much appreciate if some brave souls would test the T-STorM32, as the project would benefit from that more than anything else. So, just drop me a PM, and I'll forward the firmware and the motor module schemes to you.

The major hurdle is getting motor modules. Unfortunately I can't really help you with that, i.e., you have to build them yourself or find someone who volunteers to do it for you.
Last edited by OlliW; May 20, 2017 at 11:04 PM.
Feb 21, 2017, 05:06 PM
Thread OP

Encoders: Pros and Cons

those who have been following the STorM32 project for some while may recall my resistance to going with encoders, and the question is looming: What has changed?

The brief answer would be: My focus recently shifted to handheld gimbals where usability aspects are more important, and I got tired of certain programing "nightmares". However, I'd like to also give a fuller answer. As always, any approach has its advantages and disadvantages, and which approach is favored is the result of a - often very personal - tradeoff. When it comes to comparing the encoder-less and encoder approaches, the situation is in fact relatively complex, and the tradeoff not as clear-cut as it might seem. Also, some false rumors are around (IMHO), which is not always helpful. I thus like to discuss the pros and cons, as I see them.

Various aspects are on my list to consider:
(1) Performance: What I mean by that is the ability of the gimbal to hold the camera in a stable position, irrespective of disturbances such as gimbal motion, vibrations, wind forces, and so on. This is determined by how well the control loop works, and could be characterized by e.g. maximal angle deviation and bandwidth. It is essentially about jello and micro vibrations, which can be a signal of "bad" performance. Horizon tilt would technically also fall into this category, but it has nothing to do with the control loop and whether encoders are used or not. Thus, in the following discussion it should be excluded.
(2) DIY feasibility: I'm not doing this for professional reasons, but just for my private fun. Thus, the availability of materials, the costs and the efforts involved with a certain approach are crucial, determining factors.
(3) Usability: What I mean here is the overall user experience. This would be factors such as how difficult or easy the gimbal is to tune, how much current it draws or the duration of batteries, how robust the gimbal is against disturbances as they e.g. occur in sports or on fast-flying planes, and so on. Obviously, these factors are not about performance in the sense of (1), but can make the difference.
(4) Programing efforts: It's one thing if a feature is conceptionally possible, and another to actually put it into a program. This becomes relevant especially when many features are implemented, and all should work in all circumstances. It can make sense to choose a worse approach just because the efforts to implement a rich feature set are lesser.

Let's start the discussion.

That's maybe the most crucial, and most delicate point. Obviously, you find many people on the web arguing that using encoders yields better performance. However, to me, that is much less clear. In fact, so far I have not a single piece of experimental evidence which would clearly demonstrate this (which though might change in future!). Also theoretically, and I thought quite a bit about that, the situation is not very clear.

Three motor characteristics are (IMHO) crucial players:
* resistance, or in fact the KV value, or in fact the relation of KV to moment of inertia of the load, or mechanical time constant
* inductance, or in fact the ratio inductance/resistance, or electrical time constant
* cogging torque

Encoders allow using motors with significantly smaller resistance, and this indeed represents a huge advantage, since lower resistance implies larger KV value, which in turn implies a larger characteristic frequency of the motor (or motor+load combination). For instance, the typical characteristic frequency of encoder-less driven gimbals is in the range of 5 - 10 Hz. That means that the motor's ability to respond to and correct for disturbances declines enormously at frequencies larger than that. Notably, the 5 - 10 Hz is much smaller than the 30 fs of the video, which immediately tells that the gimbal is nearly unable to stabilize the camera at these frequencies (and jello and/or microvibrations occur). With that numbers in mind it is actually quite amazing that the gimbals do work at all. With an encoder-gimbal the KV value may be about twice as high, and the characteristic frequency pushed to, let's say 15 - 20 Hz. That's still well below the 30 fs, but much closer, and thus much helpful. In summary, this point is a clear advantage of an encoder scheme.

The effect of the inductance is an additional roll-off at frequencies above the (inverse of the) electrical time constant. This further diminishes the motor's ability to respond to disturbances. For a given motor, the electrical time constant is nearly independent on the number of windings. That is, a motor with lower resistance will also have lower inductance, but the ratio is nearly constant. Thus, choosing a lower-resistance motor doesn't help here. The typical cure is to implement a current control loop (running at high frequency, e.g. 10 kHz), which one indeed finds in all servo control or field-oriented-control (FOC) schemes. Alternatively, the motor can be constructed e.g. coreless. For instance, the Maxxon motors have an electrical time constant in the 1 kHz regime (for the EC20 it is ~1.15 kHz). With such motors a current control is not really needed, since the motor inductance doesn't diminish the performance at the frequencies of interest.

The effect of cogging torque is more subtle. It doesn't determine the bandwidth and roll-off, like resistance and inductance does. I'm actually not totally sure here, but I'm convinced by now that it is the cogging torque which is responsible for (some of) the issues with micro vibrations observed with the STorM32 controller. The starting point of the story are actually the measurements of adolfotregosa using the NT logger. These data showed signals at frequencies of about 25 - 40 Hz, which one can associate to the microvibs seen in the video and the audible "noise" of the motors. Others, including me, also did observe that phenomenon. I pondered for quite a while about the explanation of that, and were hoping that I can overcome that by just programing suitable "filters", but I failed. I in fact finally came to the conclusion that the effect is due to the cogging torque, and that in the "old" approach I can't do much against that. Encoders in principle allows one to apply anti-cogging schemes.

So, do encoders allow for a better performance? Yes, but ... it are the buts which are important here. The point is that the advantages might not be available to us.

For instance, gimbal motors with low inductance are not really available to us. Note that this is in much contrast to commercial gimbals such as those of the Phantoms, Inspires, and alike. Indeed, the Zenmuse gimbal series are reportedly using Maxxon motors, and simply by that they should have a huge advantage. The cure would be a current control loop, but Alexmos/Bascam is not doing that (nor do I).

Similar with cogging torque. Commercial gimbal builders can afford using low-cogging motors, using spherical ferrite rings. This type of magnet you find e.g. in hard drive disc motors, such as the PS2 motors I used in my micro gimbal builds (, or McTage recently used in his wearable gimbal. The Maxxon motors also use that type of magnets. In contrast, the available gimbal motors (at least all I have seen) all use this glued-to-the-wall magnet arrangement we all are so familiar with. These all have shockingly high cogging torques (there is plenty of data on rcg and fpvc showing that).

Similar with resistance. Some few gimbal motors with resistances in the 5 Ohms range are available, but they tend to be expensive. The large majority are in the 10-20 Ohms range. Using these motors with encoders doesn't yield any benefit in terms of control bandwidth or performance. Even worse, it is often argued that an advantage of encoders is that one can use smaller motors. What however actually determines the characteristic frequency is the motor "strength", or KV constant, in relation to the moment of inertia of the load (camera, brackets, etc.). Using smaller motors thus compensates the benefit of lower resistance.

So, you see, when using the typical gimbal motors and available gimbal controllers it is not obvious (at least to me) why they should give better performance with encoders than without encoders. It's as good or bad with encoders or not. Note again that commercial gimbal builders are in an infinitely better position here. I mentioned already the advantages of e.g. Maxxon motors. I'd like to also mention the Z1 Tiny2. It has big motors, with 5 Ohms, and current control (at least it has electronics on the board which looks like current measurement). In addition it is mechanically well designed. That mix is probably at the heart of it's success.

In short, as long as we just grab the 10$ gimbal motors we can't really expect P4/Inspire like video stability, with encoders or not.

In fact, my first encoder prototype (one axis only) I had up and running a year ago (end of April 2016). The test setup used a representative gimbal motor (as regards resistance, inductance, cogging torque) and no current control, and I did some tests to see if it would give me substantial better performance - but none of the experiments gave any indications of that. Note: It might turn out that there is nevertheless some significant performance gain, and that I just have not captured it by the experiments I did. That is, it will be interesting to see the real-world experience!! The NT Logger will give us the data to see that in much detail.

DIY feasibility
Using encoders might not make a big difference for bigger gimbals, larger than GoPro size. However, for GoPro sized gimbals, encoders are a financial and/or building nightmare.

The smallest suitable gimbal motors I found are the iPower GBM2804H-100T ( Let's assume they can be haved without the AS5048 encoder at a price of 35$. Makes 105$. In addition we need three motor modules. Let's assume they can be haved at 15$. Makes 150$. We now need a NT module and a STorM32 main board, which we may assume at 15+25$. Makes 190$ in total. And we have not even started building a gimbal! In comparison, without encoders we can grab a standard STorM32 board at 24$ and 3 motors at 12$, makes 60$ and we are deep in the game. We could decide to build as much as possible DIY, and the price tag could indeed shrink quite a bit, but at the expense of "heroic" building efforts. And we were not yet talking about smaller gimbals.

These reasons had been my major argument for not considering encoders: Why should one want to endure the substantial financial and building and weight burden associated with encoders if one is not getting significantly better performance? I think the reasons are still compelling. However, there are the factors "usability" and "programing efforts", and it are these which changed my mind.

Well, that's certainly a strong point of encoders. For instance, with encoders it is just plain simple to achieve both a fast startup and a good gyro calibration (see the video). Also, the motors are really quite strong in fighting disturbing forces, and the gimbal won't lose track anytime (the conventional STorM32 had an edge here over other encoder-less gimbal controllers as it did not too bad in that aspect, but with encoders it is admittedly so much better). This was one of the factors which made me rethink. If you want to use a gimbal for e.g. skiing or biking or whatever then you really want it to be robust and reliable, and not be a finky thing. Especially for handhelds the significantly lower current consumption is another biggy. It's just so annoying when the gimbal battery runs out after 1 hour. Furthermore, with encoders tuning is just a piece of cake - at least when compared to before. This is because the gimbal now behaves exactly as it is described in any text book or wiki. So, ALL the good knowledge on how to tune a PID controller do apply here fully, and can be taken advantage of. In the longer term this may make me even implementing some autotuning, since with encoders it's just so clear how to do that.

So, now doubt, when it comes to this kind of "soft" factors encoders shine.

Programing efforts
This was really the nail in the coffin. The 2nd Imu approach allows one to infer the motor position, making encoders obsolete, and do a number of good things, e.g., avoiding skipping of motor steps even on the yaw axis. However, that comes at the cost of some significant programming effort, since one needs to ensure, by implementing some sort of "observer", that various observables remain consistent, despite gyro drift (and cogging torque). The consistency needs to be ensured at any time, and with adding feature after feature this became more and more difficult. I mean, it was always relatively easy to get something working, for a particular situation, but one wants to have it working always, for all possible situations, irrespective if e.g. the gimbal is in pan or hold mode, has a STorM32-LINK connection, has .... and so on and forth. At some point I just got soo tired of permanently fighting against gyro drift and cogging torque, and working out all the transitional itches.

And at that point I stopped with working on new features such as tracking and horizon drift compensation and auto-imu-calibration, and decided to go encoders.

This became a very long piece of text. I nevertheless hope that it may help to get a more detailed picture on the benefits and disadvantages of using encoders. I think it implicitly also gave some answers to questions which one may face when building encoder gimbals.

Cheers, Olli
Last edited by OlliW; Feb 22, 2017 at 03:41 AM.
Feb 21, 2017, 05:11 PM
Registered User
Nice! Looking forward to test it! Congrats!
Feb 21, 2017, 08:03 PM
Registered User
hexakopter's Avatar
It looks really nice. Congrats! Nice to see that the Storm32 project development is always going on.

I always get a heart attack when I see your metal screws and nuts. Especially this time where you used the biggest metal tongs you could find for the <M3 nut.
Feb 21, 2017, 09:19 PM
Registered User


This looks so amazing.

Is is going to get some of the benefits that BaseCam advertises about reducing current such that you get increased battery life and can use lower resistance motors? I am not sure if you get that benefit as a natural result of encoders or if they have a specific control algorythym?

Encoders seems to have so many benefits, very excited!
Feb 21, 2017, 10:18 PM
Registered User
Encoders are probably meant for Field Oriented Control I had really good performance on my gimbal using torque control rather than the usual angle/velocity
Good to see the project is alive !
Feb 22, 2017, 02:02 AM
Thread OP
Originally Posted by McTage
Is is going to get some of the benefits that BaseCam advertises about reducing current such that you get increased battery life and can use lower resistance motors?
e.g., you should not have to rewind the PS2 motors since their 4 Ohms should be just perfect
Originally Posted by McTage
I am not sure if you get that benefit as a natural result of encoders or if they have a specific control algorythym?
that's a natural benefit of the control algorithm used with encoders
Originally Posted by McTage
Encoders seems to have so many benefits, very excited!
I'm in the course of writing up a longer piece of text where I discuss the pros and cons
EDIT: see post #3.

Originally Posted by enqz
I had really good performance on my gimbal using torque control rather than the usual angle/velocity
would you mind to share a bit more details? I had difficulties (so far) to produce clear evidence for a better performance when using encoders, see post #3. What were you doing, what was the structure in your torque control?
Last edited by OlliW; Feb 22, 2017 at 03:55 AM.
Feb 22, 2017, 10:30 AM
Registered User
I had a very good disturbance rejection (fast response and almost no oscillations). My first approach was to use a PID angle loop within a PI velocity loop, which would produce torque commands for all 3 axis. I obtained better results using a non linear P controller on error quaternion (between actual pose and goal pose).
The attitude estimator was backed up with an extended kalman filter and performed pretty well.
It works when you assume that there is almost no inertia since you should design your gimbal to have all 3 axes concurrent to the cog send me a message otherwise
Feb 22, 2017, 10:54 AM
Thread OP
thx for these info
what I was wondering was how you got the "torque" into the game
e.g., in the velocity loop, did you took the velocity determined from the encoders in the feedback?
do you have some numbers to characterize "fast response and no oscillations"?
I would call a performance "good" if the angle error stays below 0.01 with a bandwidth of, let's say, 60 Hz
Feb 22, 2017, 02:00 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
Must we use the encoder on the motor module or can I use the aforementioned AS5048? Thanks.
Feb 22, 2017, 02:16 PM
Thread OP
for the moment: yes and no
in some future: who knows

I also copy a statement I made in the other thread:
Originally Posted by OlliW
there won't be any compatibility to Alexmos hardware, I'm afraid you would have to remodel your gimbal

maybe at a later stage one could consider having NT motor module and encoder on two pcbs, and considering the ASs might then make sense, but for the moment, and I guess a long while, I'll stick with my motor modules

(the v1.1 motor modules, available in the git, actually do have an exposed spi port and can be used that way, in fact, that is what I did in my test setup for nearly a year, but I switched to the v2.3E modules)
EDIT: I maybe should add
* the TLE5012 are "just" about 5$, and in view of the overall costs I would not think that it are them which put a dent in the pocket
* there are two variants of the AS5058, the AS5048A and AS5048B ... if ever, then the T-STorM32 would only support the AS5048A ! (AM supports both)
Last edited by OlliW; Feb 22, 2017 at 02:26 PM.
Feb 22, 2017, 09:07 PM
Registered User
I can't share in details how the whole gimbal works, but think about the torque as the error quat - the actual velocity, a damped spring controller if you prefer.
As for performance my scenario only considered 10hz oscillations (sweeps <90 on all 3 axis) and it responded outstandingly, if you search in YouTube, you'll find it
Feb 22, 2017, 09:41 PM
Registered User


Not sure I can design motor modules with drivers+encoders+microcontroller that are small enough for my gimbal.

Actually, I am not sure I can design/build anything like this at all, but may be willing to try. I have been trying to learn KiCad. Being a mechanical engineer instead of electrical engineer is not helping at all.

For the sake of argument, do the drivers and the encoders have to be on one single NT module or is the NT system flexible enough that you can use 1.3x boards and put JUST the encoders on separate modules on the NT bus?

Incidentally, new basecam tiny looks like a big step forward...but still limited to IC2 IMU. Deal breaker in my opinion.
Feb 23, 2017, 03:10 AM
Thread OP
Originally Posted by McTage
Not sure I can design motor modules with drivers+encoders+microcontroller that are small enough for my gimbal.
I doubt you could, the gimbal IMHO necessarily will become somewhat larger and heavier
as said in the above, encoders DO have disadvantages, this would be one of them.

Originally Posted by McTage
do the drivers and the encoders have to be on one single NT module
when you can design and build your own pcb boards, then of course you can arrange the electronic components as you like, especially on as many separate pcbs as you like

e.g., one can use the NT motor modules v1.1, which I released long ago and which expose the spi bus on some pins, and connect a small encoder PCB to it's spi port. I even would have a suitable encoder PCB ready for use which I could release if that is what people would like to have

Originally Posted by McTage
you can use 1.3x boards and put JUST the encoders on separate modules on the NT bus?
no, the mcu's on each motor module do an important job. So, the encoders MUST be connected to the MCU on the motor module. In this point "my" encoder concept is quite distinct from Alexmos/Basecam's.

This concept is in some way a disadvantage over Alexmos/Basecam's approach, since it needs these additional 3 mcu's for each motor (maybe I should adapt the above wiring scheme to reflect that). This prevents doing what is possible with Alexmos/Basecam's controllers, namely connecting the encoders to the main board and using the motor drivers on the main board. This would be cheaper, and provide a much easier entry to the encoder world.

BUT, I don't like this approach, it's not NT-ish, and I'm actually convinced that on the longer run the concept with a brain power for each motor will have it's advantages. As it had e.g. for the NT imu modules, which have now a much more sophisticated filtering scheme (Alexmos/Basecam just can't do that), store their own calibration data (just look at how clumsy the solution of Alexmos/Basecam is), or have some NT camera functionality integrated. The STorM32's NT concept has some strong points (IMHO).

Quick Reply

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Cool T-STorM32: The best STorM32 ever !? OlliW Multirotor Drone Talk 2 Feb 21, 2017 05:02 PM