Instructables

This is a Spring 2014 Electronics project at Pomona College created by Andreas Biekert and Jonah Grubb. Thanks to Professor Dwight Whitaker, Tony Grigsby and the Pomona Physics Department.

Our goal with this project was to create a 2 axis brushless gimbal controlled solely by an Arduino Uno with input from an accelerometer/gyro. A gimbal is a camera stabilization system that uses motors to correct unwanted camera motion. The goal is to create perfectly steady footage, although smoothing out any bumps is a reasonable first benchmark. "Brushless" refers to brushless motors which we will explain more about later. All the other gimbal projects we found are controlled using fabricated gimbal control boards so we wanted to approach the project from a more fundamental level. Our hope was to create brushless gimbal control without this kind of board, but rather using the more general purpose Arduino Uno.

We're going to have to be upfront; we never got the gimbal we were looking for. However, we did learn a lot about how the device should work, so we have written our thoughts on improvements and directions to pursue with the project. We hope this is at least a good resource for a starting point. Let us know if you have any questions or suggestions for improvement.

Between learning how to control the brushless motors and interfacing with the accelerometer we consulted quite a few sources for this project. We will be referencing material and using photos from this project, which served as our foundation for brushless motor control. Our code is heavily based on both the aforementioned motor control project and this I2C library with sample code for an MPU6050 chip. A big thanks to both of these projects for giving us direction in our efforts!

There are several ways to go about getting the parts for this kind of project. Naturally, one of the principle components is the Arduino Uno.

We bought a frame and brushless motor set on Amazon: Frame and Brushless Motors. It's probably possible to machine or print your own frame, but we were more interested in the electronics portion of this project, so we went with the quicker route of simply buying the frame ready-made.

We also bought our accelerometer off Amazon: Accelerometer/gyro. The GY-521 breakout board is significantly cheaper than any other MPU6050 models we found, but it worked just fine for our project. However, we did manage to break one and had to order another one. We still aren't sure if its failure was our fault.

We used two Mauser 511-L298 h-bridges (with heat sinks) to control the motors---more on that later. These are able to handle the higher voltages and currents needed to drive the motors so they can move the frame and camera.

Some other small components we used were two 2.2k resistors, three 0.1 microFarad capacitors, and a lot of wiring :)

 
Remove these adsRemove these ads by Signing Up
chrwei5 months ago

the notes for the GY-521 on http://playground.arduino.cc/Main/MPU-6050 recomend to use 5V to VCC, not 3.3V. I suspect what was happening is that adding the motor controller made just enough of a drop so that 3.3V would no longer work, and adding additional resistors stabilised it. you may not need the extra resistors if you power the breakout on 5V

Good catch! Would love to try this out, but currently we are moving out for the semester so the setup is packed up. We are still looking to work on this in the future, so thanks a lot for your input!

Iceberg863005 months ago
Hopefully I can help out a bit. Think you got ripped on those motors. They seem pretty small, but I'd need to know the Kv and torque constant. I can tell you that a motor used on a 700 size heli is usually around 450-500 Kv, runs on 12 cell Lipo battery, very high torque, and costs about 4 times what you paid for the entire gimbal assembly. The motors you have are high mag pole count, so better for positioning purposes, but they generally require high timing values during accell and deccell. Some want 15-20 degrees.

I don't know what your PWM frequency is, most RC speed controls run from 8-16kHz. This can and does wreck havoc on electronics. When run off a battery it creates a nasty ripple where the power hits your electronics, and the longer the wires from the power source to the electronics shots up the inductance and makes the ripple worse. This can and does kill electronics. Fairly large caps are usually placed at the electronics to help smooth this out.

Don't know if this would make a difference or not because I haven't looked at the h bridge data, but the phases are usually switched with 6 power FETS with built in diodes acting as a flyback circuit when the FET is switched off.

Now, because you have no position feedback from the motors, ideally you should run them through a reduction drive. Some hall sensors could then give a lot of resolution with a real reduction in the chance of losing the motor position.

There it's also an awesome chip out that is a magnetic encoder. It has a few hall sensors in the package, and uses a circular magnet on our in a shaft over the chip.

Something like this is really required, you have the motor position servo loop inside your camera position to vehicle servo loop. Just like what you were proposing.

Now we aren't talking motors that have an encoder with a Z pulse, so upon startup you have no way of knowing where the motor is electrically. When working at Haas I was adapting a third party motion controller to our servo amps. Our amps used sinusoidal commutation, with 2 inputs for 2 phases from our in house controllers, the third phase was then calculated inside the amp.

Now, the in-house scheme was to drive the motor very slowly and when the Z pulse hit the electronics would sync up with the motor position then continue driving to limit switches to pick up machine zero. These were fairly large servo motors comparatively, and were being reduced through a ballscrew or rack and pinion.

I got a cheap third party 4 axis controller. However, because the amps needed 2 analogue ±5 volt signals to command the sinusoidal I had to combine 2 axis into one. Upon startup a zero command had to be given, driving the phases hard so the controller could sync. Not exactly the greatest method because driving the phases so hard to ensure a sync the machinery would jump quite significantly.

Personally, for this purpose I wouldn't worry about true sinusoidal commutation. You're wasting quite a bit of processing power that would be served better grabbing quad encoder signals and using 9 or 18 voltage steps per 180° of commutation, and using something to reduce the motors.

These little guys aren't really made for holding a specific position, so they will get hot if you're feeding too much current. A reduction drive will give you more torque at lower currents and better position resolution.

I know this was kinda a lot of info and ask over the place, but hopefully it will help you out. Any questions let me know.

Also, goto freescale website and search app notes for DC motor control. There are a few good apps that use cheap hcs12 16 bit MCU. I'm sure the methods can transfer over to the arduino.

However, if you are going to go for true sinusoidal commutation (really is the smoothest and most efficient method, but I was a Mechatronics Engineer at SLO, so the servo amps were like black boxes to me, Haas supports engineering pretty well, so you may be able to get some theory out of them, our possibly even a servo amp or 2, but they will be 45 amp units at least, a little big for RC gimbals lol. Can give you a name or 2 of people that could make that decision, but because of the units you'd probably have to come up with a lab exercise for servo motor control, wouldn't surprise me if you got amps and motors out of them if your proposal is good enough. Like I said, the smallest amps and motors dwarf what you're working with and would be mainly for learning about and developing a servo control, not actually developing signals sent to the motor a as the amp does this. But you would need to read the encoder and come up with something to feed the amps.)

Back to your project, Haas uses or used several coldfire processors for motion control, HMI, etc. So you may end up using several arduino MCU to get the job done. 1 to close and control each motor position servo loop (in commercial motion control this seems popular, you have an amp/servo that is fed by a master controller, much like stepper amps/motors fed by a parallel ports pulses.) Then another for the sensors and motor position commands to close the camera orientation servo loop.

Again, let me know if you have questions, delt with CNC in industry, and quite a bit of experience in the RC world.

sorry for typos / grammar, tablet doesn't like me.

Hey, thanks for your detailed reply! First, a confession; a lot of your details went a little over my head (I'm a physicist, not an electrical engineer ;) ), but I can definitely get a sense of what you are talking about. Part of the goal of this project was to work as cheaply as possible and to get things working one step at a time; no doubt we would love to add things like hall-effect sensors and multiple Arduinos down the line, but we simple avoided solving problems that required spending more money for economical reasons.

Having said that, we definitely got a sense that our motor control was a little off, so that's one of the areas I'm most interested in developing. I was quite interested in your comments the HiZ commutation mechanism and how exactly that works. The motors we used were only 90kV... not too powerful. However we definitely felt we could get enough torque out of them, except for the freezing of the Arduino. Another user mentioned we were using the wrong VCC for our accelerometer breakout, which is definitely another simply fix we could test.

Unfortunately we disassembled the setup since we are in the process of packing up and moving out for the semester. However, we are definitely interested in continuing with project in some vein, so we'll get back to you if we have any more questions!

monobits5 months ago

The resulting video is awful... :( Any chance to see a working prototype that's better than that?

Jonah Grubb (author)  monobits5 months ago

If you read through the whole thing, you'll see thats the best we got it to work so far. We had lots of problems with electrical noise making it impossible to get a perfect servo. Something we are looking to improve in the future. But thats what it is so far.

As an add-on to that, perhaps a little careless of us but the sample video is set to servo to a specific angle (like 5/20 pitch/roll or something) as a way of making sure that the motors weren't just going limp. For a better video we probably should have gone 0/0, but unfortunately the setup is currently disassembled, although we may return to it down the line.

家廖5 months ago

I am dizzy, Gimbal compensation effect does not seem to.

marhar5 months ago

This is a great instructable. The things I really appreciate are:

- there's some good material on the theory, etc.

- you document the process you're going through -- also very educational!

It's great that you put this out as a Work in Progress, rather than waiting until it was tidy and wrapped up. I hope more Uni projects get documented like this!

bygreencn5 months ago

doing one.

bob30305 months ago
Cool. Thanks for sharing.
gravityisweak5 months ago
Excellent. Most of the theory behind this is beyond me, but I like the ible nonetheless, hopefully someone will run with your idea and we will have cheap, open source gimbals out there!
Jan_Henrik5 months ago

very cool!"

Nice