3D Robotics

More gimbal news


For this post, we want to let you inside 3DR by providing a look into the overall management process for a product like the gimbal. In the past we’ve focused mostly on technical matters, so we hope this is an interesting change of pace.

To cut to the chase: we were not happy with the performance of our gimbal over the past month while we’ve been tuning performance. So we decided to make it better, which means starting production this week (first week of August), not in late July as we last promised. This was a tough decision, to be sure - this post explains our logic.

So, first things first. The gimbal performance we were seeing wasn’t bad. In fact, we were right in that gray area where we could have reasonably decided to ship it right now.  Our user tests on “naive users” - people that haven’t seen much aerial video - were uniformly positive. But with a trained eye, you could see movement in yaw in windy conditions.

So, we had a decision to make. Ship the gimbal as-is, or make it better. We decided to make some changes to make our gimbal work great, even if it meant taking a little longer to do so.

Decisions like this are always challenging because they aren’t black and white. At 3DR, one of our guiding principles is to prioritize the user experience (UX) over schedule over cost. We write it this way, as system of inequalities:

UX > schedule > cost

If you ever come to 3DR, you’re likely to see this little equation on whiteboards, in notebooks, in our internal docs.

We know perfection is impossible. Nothing we will do is ever going to be perfect. It’s hard to even write that sentence, because at 3DR, we strive for absolute perfection. Sounds pretty hokey, right? But that’s really the way we work.

And while we know we may not achieve perfection, there is some difficult-to-define point where the team can say, “That looks good. I’d put my name on that. Let’s ship it.” Not all companies have enough synchrony across engineering, design, ops, marketing and every other team such that the whole group hits that point at about the same time. At 3DR, we do have that synchrony. And we just weren’t feeling like the system was ready to go.

So specifically, what weren’t we happy with in the gimbal performance?

Over the past month, we’ve been tuning the performance to get the gimbals to stabilize well across the unavoidable variance of the manufacturing process. In so doing, we pushed our software control system really hard.

At some point in that tuning process, we got together to try and understand how much more performance we could get purely out of software.

Taking a step back: in any hardware/software product, whether it’s a thermostat, fitness tracker or drone, there’s an interplay between hardware and software engineering. The hardware sets the bounds of what software can do. Software can move fast to improve things but cannot operate outside the basic design of the hardware. Hardware is slower to develop, but can open up new territory for software performance and features.

In our case, the weight (or lack thereof) of the top part of the gimbal compared to the bottom part taxed our yaw motor’s ability to correct for disturbances in yaw. Basically, when the copter and gimbal get hit by wind or other disturbances, your video might look like it is vibrating or drifting from left to right. There’s a lot of technical detail here that I will omit, but our decision boiled down to: leave performance as-is, or find a way - a way that would add time to the schedule, no doubt - to address the yaw wandering.

We did find a way. Adding mass to the ends of the spider bracket - the piece that holds the dampers on the gimbal at the very top of the assembly - increases the overall mass of the top part of the gimbal. This allows the yaw motor to react to and correct disturbances hitting the bottom part of the gimbal where the camera lives, resulting in more stable video.

This improvement is relatively straightforward to implement in mass production (as much as anything is straightforward to implement in mass production), so we decided to go for it (after, of course, designing and testing the improvement).

It wasn’t an easy call. We know we could work on the gimbal forever and it would get better each day. We set strict requirements and checklists during our product development process to make that process as efficient and objective as possible. But at the end of the day, it boils down to a subjective, qualitative, ineffable judgment call - “That looks good. I’d put my name on that. Let’s ship it.”

We are very eager to get this gimbal out to you! Solo’s not complete without it. And we know not to let perfect be the enemy of the good. Actually, that’s not quite right - good isn’t good enough. I’ll rephrase: we know not to let perfect be the enemy of the great.

So that’s where we stand. We made some changes and started production. We'll check our product thoroughly before we ship the units. Fixing yaw wandering is only part of the story - there is so much more work that has gone into the gimbal (and is going into the gimbal, and will continue to go into the gimbal via software updates) that I don’t have room to describe here.

But the decision to improve the product and take the schedule hit vs. shipping as-is seems to me to be the most interesting thing to share with you all.  We hope we’re painting a clear enough picture - perhaps with this information, you could even imagine yourself here at 3DR, doing this work, and making these decisions.

Thanks for your support and patience. We’re continuing to work hard on your behalf.

Finally, most important, here is some video that does not include any of the recent tuning, but has a version of the latest hardware. This was shot by one of the 3DR team, Jon.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • I have full faith. 3DR gimbal would be the best. it was long over due. what I suggest is that the gimbal should be able to accommodate common point and shoot cameras and not only hero cameras. this can be done by having an extra optional bracket for camera mount

  • Hi Jeevan,

    Good explanation and good reason for making last minute change,

    Torque reaction against a softly mounted top plate.

    Frustratingly difficult to predict or assess.

    Possibly what would be most helpful is getting out in front of these occurrences and letting your dependent customers know the reasons for a protracted delay as soon as you realize it is going to happen instead of waiting for many grumbling voices after the fact.

    You did a great job with this Blog, but a month earlier would have been a lot more beneficial.

    And from what you have said, you knew at least most of this a month ago.

    Your customers would a lot rather feel involved with the process rather than as an after thought.

    Just a thought.

    And Marco - superb video / gimbal performance!

    Best Regards,


  • Purely from a rank amateur engineer's point of view, it looks as though the moment of inertia of the assembly in pan is at the heart of the matter. The length of the tilting motor beside the landscape mounted camera takes alot of  torque in the panning direction. A shorter motor with consequent larger diameter motor might help, but it really looks like the more complex arrangement of having the motor behind the camera needs to be considered.

  • Developer

    @Eric @Paul, thanks, it's the result of years of hard work.
    I hope the gimbal of Solo will work better than this one...

  • like the camera is nailed on the sky

  • @Marco Amazing... Impressive how you can see the copter moving on top of the frames but nothing moves on the scene

  • @Marco - wow, that is really stable footage!

  • @Rob - I get that. I was really more proposing the other idea, which was to actually explicitly consider the dynamics introduced by those isolator mounts (which you would keep), and then design a controller to manage those dynamics (sort of like what was done in the second paper).

  • Developer

    The dampening system is the key part, with "wrong" antivibration system the gimbal electronics are unable to compensate, GoPro is very susceptible to vibrations, i've much experience in these things.
    For example in this video i used a particular anti-vibration system (home made), and there's no vibrations, no post stabilization (you can see the vibration of the frame).
    To achieve this result i've worked weeks only with the dampening system, the Pixhawk and gimbal PID, and and the residual vibrations of the propellers and motors.
    Working exclusively on the gimbal can not lead to good results, also a different Solo parameterization can be helpful.
    I agree, "perfection is impossible" but you can approach a lot to have almost perfect results.

    My two cents...

  • Developer

    I watched several time the video of Jon and i'm not excited, i see some little vibrations in the distant horizon details, and is practically still hovering, with a very low ambient light.
    What i wonder is how Colin with her Solo and the same gimbal get amazing results, super stabilized video, with the quad that moves quickly (
    for example in the video filmed in Malta).
    Someone in 3DR can explain this?

This reply was deleted.