Blogs

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.