Inside 3DR: A look at the gimbal development process

At 3DR we are big believers in open — both in terms of software development and in terms of communication with our community. We’ve lately been hearing lots of questions about the Solo Gimbal — when will it be out? why isn’t it out yet? what can it do? how good is it? — so we thought we’d open the doors and share some insight into how this complicated product is progressing.

We will be keeping these doors open until we ship the gimbal — you can expect updates from us on about a weekly basis. Our goal is here isn’t to answer every question (we wish we could), but to share more about the product development process of something as complex as a 3-axis, super-advanced gimbal.

We’ll tackle some initial questions now in this post.

How good is our gimbal?

Here’s a sample of some video one of our flight test folks, Terrence Williams, shot recently on a prototype Solo and prototype gimbal:

Solo in Oakland Video (With Adobe Premiere Warp Stabilizer set on Position, Scale, Rotation at 25%.)

And here’s a video of Solo’s Smart Shot modes that we filmed with the gimbal in one flight, with one battery, in Cabo — zero post-stabilization on this one.

We are pretty happy with these! We’re working on more improvements in software, but we believe we’re off to a good start.

Who is doing the work?

Designing something this complex at high volume is a big effort.

In our case, the core engineering is being done in Berkeley and San Francisco, partnered with a firm in Austin, and with 3DR engineers flung across the globe, from Brazil to Australia. We’re producing the gimbals at a super nice factory in Guangzhou, China.

Where are we now? And how does product engineering work?

We currently have fixes for a variety of issues, which we’re testing now in California and soon in our factory in China. We are also working hard with the GoPro team to ensure the GoPro control from the mobile app works great.

In terms of schedule, the Solo Gimbal is set to enter a “DVT2” phase that will quickly turn into “PVT.”

…let’s next explain what those acronyms mean!

Most hardware product development processes follow a similar pattern. Whether you go to Apple, Fitbit or 3DR, you’ll usually see the same acronyms — DVU, EVT, DVT, PVT. Generally, this process takes between 12 and 24 months, from first concepts to products ready on shelves.

Early on in the product development process, the core engineering and design team will work on a series of prototypes. At some point, the team feels confident that they have a design they’re ready to release to manufacturing — this is usually called the DVU (“Design Validation Unit”).

At this point, you begin to invest heavily in manufacturing tools — plastic injection molds, inventory and so on — so you need to be confident in your design. There is a long waiting period — 8 weeks is common — while these tools are built, so during this time the engineering team will focus on work in software and electrical.

Once the factory is able to produce its first units, you see a series of prototypes called EVT, DVT and PVT. In the EVT (Engineering Validation Test) phase, the factory will attempt to reproduce the DVU — generally there are lots of things that don’t quite work about the EVT unit, so this is a big learning experience for the company and the manufacturer. These issues are addressed with the next step, the DVT (Design Validation Test), which corrects many of the issues discovered in the EVT; the DVT also provides the first opportunity to try out the mass production assembly line, including test fixtures and so on. At this point, the goal is for the DVT unit to look like and work like the product spec pretty closely. Finally, in the PVT (Production Validation Test) phase, the company and manufacturer make a limited run of products that are actually sellable units.

For complex products, a fourth or sometimes fifth iteration is introduced (e.g., EVT2 or DVT2) to reduce risks that crop up during the development process. The Solo vehicle, for example, had a DVT2 phase to help us fine tune things like the antenna design.

baVMN_D7vTLDmn6NeYnjy_flXsBc5SRtfrfL4-va4Cs

The 3DR team is currently testing some fixes in the gimbal DVT2. These include an issue in which about 2% of the units built to date will occasionally over-current the motors. Again: We have a fix for this issue in place, and we want to test it thoroughly before releasing the gimbal to the public. We understand that 2% doesn’t seem like a lot — many products would launch with a yield this high (98%) — but we are laser focused on increasing the quality of the user experience so we want to eliminate even risks of this size.

Another issue we’ve solved is making sure that the flex cable — the flexible cabling connecting the control signals and HDMI from the GoPro to the Solo — are properly spec’d (impedance matched, in the case) so that we have stronger guarantees on long-term quality. So far, the gimbals we have work well with regard to both controls and video, but we need to be pretty specific about these details so that we can reduce the risk on long-term issues for our customers.

We’ll talk more about our problem solving in future posts, but we hope that this taste of product engineering gives you a sense of the size and complexity of issues that companies making mass scale products must address in order to ship a product to customers with the highest confidence.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s