Gimbaled thrusters, aerospace-grade adhesives, carbon-fiber-reinforced polymers, and inertial measurement units. This is a space project!

Similar projects worth following
[note, as of 10/9/2016: this project is in 'deep storage' and has been for some time now. I may re-engage with it at some point but for now consider GimbalBot to be a cautionary tale in ambitious aerodynamics.]

GimbalBot is a stabilized UAV that hovers and balances on a contra-rotating gimbaled fan powered by off-the-shelf RC brushless motors. The vehicle is constructed from commercially available carbon-fiber-reinforced polymer (CFRP) plates, angles, and tubes, fastened together using aerospace-grade epoxy. Attitude control is accomplished using differential thruster RPM and servo-actuated thruster tilting. A MEMS IMU running through a Kalman filter provides angular orientation data to a vehicle-mounted Arduino Due for control.

Everything about the project--schematics, iterations, mistakes, decisions, firmware, CAD models, BOMs, costs, board layouts, crashes, calculations--will be shared.


I started the GimbalBot project on April 30, 2014. GimbalBot is an open source unmanned aerial vehicle intended to explore a diverse range of topics including airframe design, aerodynamics, composites manufacturing, embedded systems, sensor fusion, and stability control. The craft combines characteristics from ball-balancing robots, rocket-stabilized landing vehicles, and single/dual-propeller drones that use actuated fins for attitude control. 

GimbalBot's unique vectored fan design isn't meant to win any awards for efficiency, speed, maneuverability, cost, or other performance targets traditionally driven by business needs. Rather, I hope to share my own process of discovery and learning as I research and apply new (to me) concepts to a real-world project. If GimbalBot actually manages to get off the ground, I will be truly ecstatic.

System Design

GimbalBot Hardware System Design (*.pdf)

GimbalBot Firmware System Design (*.pdf)

Hackaday Prize Entry Video - Phase 1


GimbalBot is Open Hardware. Every aspect of this project is open, and this has been a fundamental design decision since day one. By sharing early concepts and models via a constant stream of project logs, I've been able to gather a vast number of invaluable suggestions that have been integral to the success of the project to date. I hope that by keeping my methods and decisions in the public eye, someone might learn from my mistakes and build on what I have learned from GimbalBot.


In its current iteration, GimbalBot isn't a connected device in that the craft does not directly interface with the Internet. However, the project does feature several local systems that are connected in various important ways.


GimbalBot uses several sensors to keep tabs on its orientation in space, including a 3-axis accelerometer, a 3-axis MEMS gyroscope, a 3-axis magnetometer, and a barometric altimeter. All of these sensors communicate digitally with the Arduino Due over I2C and provide data at a rate of 50-100 Hz. I2C interpretation will be handled using the standard Arduino Wire library.


The pitch ring servos and brushless motor electronic speed controllers (ESCs) are all off-the-shelf hobby R/C products, and as such use a standardized PWM interface for control. The standard Arduino Servo library will be used for encoding these signals.


I'm reinventing the wheel enough with this project; for now, I'll be using a commercially available (and as-of-yet unselected) R/C setup with a dedicated receiver. While these systems often have sophisticated mixing and scaling features in the controllers, I plan to feed the raw receiver output through a PPM converter (to save on I/O lines) to the Arduino and deal with scaling issues in firmware. Since the RF protocols for these systems are generally proprietary, I'll keep the receiver interface open to ensure cross-compatibility with other radio platforms.


One of the most interesting parts of the GimbalBot project involves the control loops used for altitude, pitch, roll, and yaw control. In order to study and understand the interactions between these control systems and GimbalBot's various sensors, the craft will be fitted with a dedicated high-speed telemetry system for gathering sensor data and changing loop tuning parameters on the fly. While this system has not been designed in detail, I plan to use something like the XBee-PRO with a suitable computer interface.


I plan to release GimbalBot under the MIT license. This license will cover the on-board firmware, computer-side software, and all CAD part models, drawings, assemblies, and *.stl files. In other words, if you want to build a GimbalBot and sell it--please do. I still need to double check the licenses on the libraries I'm using for compatibility, so this may change in the near future; in any case, everything I do here will be entirely open and free for anyone to use without restriction.


In addition to a lot...

Read more »

  • 2 × Suppo 2810/9 brushless motor 1350kV, 500 watt maximum power
  • 2 × KDE XF UAS 35A+ ESC 35amp+ brushless ESC
  • 2 × Gemfan 9x4.7 CFRP prop
  • 1 × ZTW 12A external BEC Power supply for servos and board
  • 2 × Hitec HS-8360TH servo Titanium gears, 0.06 sec/60 deg, 16 kg-cm torque, digital.

View all 16 components

  • Bit the bullet, bought RC gear

    zakqwy03/02/2015 at 04:12 3 comments

    Should have happened 6 months ago. I got sick of putzing about with short range USB toys; time to step up my control game. Next week this shows up. The FlySky FS-TH9X isn't the fanciest transmitter around, but enough people seem to like it that I think I'll be happy. Extra bonus for getting 8 analog channels with a receiver for under $100. Excitement levels are building!

  • Hover Test Follow-Up

    zakqwy02/25/2015 at 23:32 0 comments

    Okay, I was pretty excited when I posted the last video. First tethered hover test! Yay!

    Lots of stuff to figure out prior to the next hover test(s):

    1. Power: Enough with the damn LiPo setup and the 4-minute test limitation. I need shore power that will let me do sustained tests.
    2. Control: The USB mouse setup was hilarious but less than ideal. It may be time to bite the bullet and buy the RC gear (transmitter and receiver). Or spend another ten frustrating hours trying to get a damn Xbox360 dongle to talk to my Due.
    3. Safety: Thicker tethers that can't break, and (most importantly) a bit more distance between me and GimbalBot. I wasn't concerned with the previous test; while I did snap one cable, I still had the other, and the camera angle made it seem closer than it was. Even so--GimbalBot is scary and needs to be treated with respect.
    4. Data: Time to start gathering massive amounts of it. At the very least, I want throttle position, X/Y gimbal position, and IMU data at a fairly high rate. That means, most likely, serial datalogging via USB. My desktop PC isn't terribly mobile so I'll need to come up with another setup--maybe an old laptop, of which I have several.

    Thus far, I've made significant progress towards solving (1) by purchasing this today:

    Yup, it was time to step up my power supply game: 0-20 VDC, 0-50 A. I'll be able to comfortably emulate the 4S LiPo (16ish VDC) and provide plenty of current for both motors. I've been needing an excuse to install a 220 VAC drop in my basement, so... this will do. Shipping was more expensive than the actual power supply; either way, it should be here next week.


    zakqwy02/19/2015 at 00:48 9 comments

  • Frustratingly close

    zakqwy02/17/2015 at 05:22 1 comment

    GimbalBot is hanging by an elastic band from the rafters in my basement, secured below using steel cables with plenty of slack. My benchtop power supply, a massive LiPo battery, and a hastily thrown together USB mouse based (no joke) interface are all strapped to an adjacent sawhorse. Everything is ready to go for the inaugural hover test.

    Something had to go wrong, right? Well... I didn't quite take enough slack out of one of the ESC leads, and it got sucked into the lower prop upon first startup:

    Time for bed. More testing Wednesday.

  • Thermal Performance Testing, Part 2

    zakqwy01/27/2015 at 03:09 12 comments

    TL;DR: back to the drawing board. Or maybe it's time to try for a hover test, and tell thermal issues to go to hell?

    I ran seven tests this evening. Main changes since yesterday:

    • Increased the motor pwm signal to 110 degrees. I wanted to put some heat into the coils!
    • Changed the program around a bit--now the button starts a 120-second test.
    • Tried to be a bit more consistent between runs--I started each new run once the temp hit ~30 C.

    All data is in the repo; here's the summary graph:

    So--what's up with the jagged lines during the actual motor run? Well... seems when I went from 100 degrees to 110, the TC signal got totally garbled. I backed off to 100 degrees and the problem seemed to go away; however, the presence of the 'NAN' (not a number) results from the MAX board makes me more suspicious of the temp data. Hence the subtitle on the graph: "don't trust temp values at speed, we just want max values!" I made a habit out of unplugging the ESC power supply as soon as the run finished, which helped keep the post-run ramp up to Tmax nice and clean.

    Okay, enough chitchat. Maximum motor temperature values for each run:

    So... max temp increased by 20 C or so going from the control group to just using the nozzles. Worse, the venturi didn't seem to improve anything; I ran out of time before rounding out the tests, but I'm guessing the difference between the nozzle runs and the venturi run isn't statistically significant. Clearly, the motors do better without cooling ducts, and it doesn't seem like the venturi did anything!

    Other details: I measured current (via a shunt) and voltage going into the ESC and it remained almost completely stable. Thrust dropped by 50-100g for the last four tests; maybe the motor overheating caused issues here? I'm not surprised that the venturi test dropped the thrust a bit, since the 3D printed insert does cast a bit of a 'shadow' downstream of the propeller.

    So what's the takeaway here?

    • Lots of smart people probably spent a lot of time designing the cooling system for the motors, so it's probably pretty good as-is. Keep it simple, stupid!
    • I learned a lot about serial data acquisition on the cheap, thermocouple noise, 3D printing (first 3D printing project!), and... well, you know how it goes when an experiment doesn't work as planned. I've learned this before, but I was reminded about how important it is to try out ideas even when there's a good chance they will fail. It's also just as important to share the results with the world--if nothing else, maybe this will add a data point for someone else trying to improve the cooling system for their quad.

    I'll put it to a vote--if you've made it this far reading, what do you think I should do? Put GimbalBot back together and see if it will fly?

  • Thermal Performance Testing, Part 1

    zakqwy01/26/2015 at 01:28 0 comments

    Ha! This project isn't dead! Just resting.

    I finally got started on thermal performance testing. To review: Using the larger (9") props seems to give me adequate thrust, but the motors heat up a bit too quickly. I went on a severe tangent designing and 3D printing motor cooling ducts and various venturis, and modified the motor mount to accept these new parts.

    In order to prove (or disprove) the efficacy of the parts, I also embedded a thermocouple in the motor frame to track its temperature in real time during tests. Okay, to be fair--embedded is a bit of an exaggeration. I filed a groove in the motor bracket, globbed on some thermal transfer compound, and smashed it against the back of the motor frame:

    I also put together a pretty simple data acquisition and control setup using a Pro Mini, Adafruit's MAX TC board, and a handy serial datalogging program called GtkTerm. I included a few run status LEDs, a button (yup, it's my favorite giant red button) to start the prop rotating, and a servo to indicate the current ESC signal:

    The first test was hilarious. It's been awhile since I've worked on GimbalBot so my work area wasn't quite to prop-safe levels of cleanliness. I ramped the motor up for the first time and heard a loud BANG--never a good sign. The prop had sucked up a stray Home Depot receipt and exploded it:

    I broke for a bit of cleaning and then started running instrumented tests. Since the last time I've posted, I've finally entered the 21st century--I've got a GitHub repo now! The Dropbox directory still holds pictures, models, and old code; however, I'm going to start using the repo for firmware if not other stuff moving forward. Navigate to GimbalBot/data for the first performance tests, or just look at this graph:


    1. 3 runs under identical conditions
      1. Motor PWM output: 100 degrees
      2. 8" props (nothing crazy yet)
      3. Thrust: 1210-1215 g
      4. No fancy cooling setup--cooling ducts removed, holes taped over
    2. x=0: motor turn-on from ~25ish C
    3. Various motor cutoff points, shown by the temp spike (I estimated these)
    4. Some data points eliminated due to noise (the TC board returned 'nan', or 'not a number')--hence, somewhat jagged spikes. Linear extrapolation for missing data.
    5. Data acquisition rate: 2 Hz

    The program is set up as a "dead-man's switch"; that means I had to keep the button down to keep the motor running. I did this mostly for safety reasons; in the future, I'd like to standardize the test time so the cutoffs happen at the same point. A few takeaways:

    • The motor temperature stabilizes eventually, but the approximate stability point varies by ~10 degrees or so across 3 runs. I'm not sure if this is due to thermocouple drift or air temperature variations or something else; maybe I should run more tests with identical conditions.
    • The slope of the heat-up seems pretty consistent. I should probably quantify this with an error and use that to compare performance.
    • Motor temperature takes a big spike up as soon as the prop stops rotating! Looks like the motor's built in cooling ducts are already doing something here; the temp rise after motor shutdown is 15+ C, and it happens fast.

    Okay, hypothesis time!

    • Cooling ducts vs taped over holes will be an improvement with venturis or no venturis. More airflow, right? Hopefully?
    • Best performance will happen without any venturi insert (just an open hole). Why? I think my venturi design will restrict airflow too much and the venturi won't generate enough DP to flow very much air through the relatively small holes in the elements' necks.

    Stay tuned..

  • A few on-the-fly changes...

    zakqwy10/21/2014 at 01:51 0 comments

    It's a hacking project, right? That means unexpected last-minute changes! Also, lots of updates that lack significant progress. Oh well, one step at a time.

    First of all, I apologize for the quality of these pictures. My cheap but effective camera seems to have a dead battery (I forget to charge it on occasion), so these were taken with my phone. I wasn't terribly careful so they might be somewhat blurry. I'll let the photos and italic captions tell the story.

    I used the Dremel with a skinny diamond bit to carve a pair of diagonal slots under the motor mount plates as per the CAD drawing; however, I ran to some issues with getting the 1.6mm CFRP plate to slide into the slot cleanly. It fits tightly for most of the length of the slot, but I had some issues at either end--it's tough to get the bit in without buzzing through the motor mount plate. Worse, even after a fair amount of work with a thin metal hacksaw blade (now extremely dull), I realized that the CFRP plate was quite close to the outlet of one of the cooling ducts. I don't want to create an unnecessary pressure drop. Then it hit me... I don't need the slot at all. Or the CFRP insert. I don't need to divide the exhaust from the motors between the two venturi tubes at all. Man, I wish I'd thought of that before severely compromising the structural integrity of the motor mount. Oh well, nothing a sketchy patch can't fix, right? For testing, I'll probably cover the slots with tape.

    No real drama cutting the vent holes for the motor, although I did almost mark them improperly when mocking everything up with the motors. Rather than further dulling my HSS drill bits I opted to cut these using the diamond bits.

    Fitment is right on the money. Yes, CFRP dust tends to get caught in SLS parts, so they look dirty. The vent inserts stay in pretty well so I probably won't glue them in for testing; once I've got everything sorted I might epoxy them and use some silicone to make a form-in-place gasket to reduce leakage around the motor connection. Or likely not.

    This cut went fairly well. Again, I used diamond rotary bits for everything and checked fitment several times.

    Uh oh! Yup, you guessed it--I wasn't able to maintain a sharp edge around the curved portion of the square tube and ended up losing a few millimeters of height. The air gap would be a serious issue, unfortunately. I was afraid this would happen, but it's a good excuse to install a few reinforcing strips that should probably be there anyway.

    Several chunks of CFRP getting glued a clamped here: two side pieces for reinforcement and air sealing (I'll use RTV or something to ensure a good seal) and two tiny scraps to prevent the venturi from falling through. I thought about leaving a tab when I cut the CFRP, but I didn't really have a good way to interface that tab with the venturi insert without some modification of the SLS parts. Man, the rapid prototyping department should really spend more time communicating with the composites department.

    I had the glue out, so I also glued a few tabs that I'd cut earlier onto the fan shrouds. I'll need to drill matching holes in the motor mount to hold these on during testing.

  • Thrust Testing Rig v2.0

    zakqwy10/09/2014 at 02:48 0 comments

    The fun thing about over-engineering stuff (or not really engineering it at all--just over-building it) is that you can throw things together without much regard for precision. The updated thrust testing rig fits this description nicely. I also managed to build the rig with minimal additional cash outlay--I grabbed a pillow block at my handy neighborhood surplus store, but most of the other stuff was already floating around my basement.

    The new rig is designed specifically to test a single propeller on the motor mount, leaving room for motor cooling venturi tubes and such. I thought about recreating the motor mount with a spare chunk of CFRP square tube, but this seemed a bit wasteful. As such, the clamping mechanism is a bit awkward (especially since I re-used the aluminum extrusion from v1.0), but it's easy to use and quite secure:

    The two bolts aren't tightened in the picture, but when I torque them down the motor mount is fairly secure. Well, minimal rattling.

    Thrust Testing Rig v1.0 was heavy, mostly because its base was a ~5' 2x8 I had left over from another project. For v2.0, I used a mounting bracket scheme that fits to my desk; the rear part loops around the (annoyingly narrow) lip of the desk's surface, and the front bit uses a few removable brackets so I can take it off easily for transport:

    I might move this down a bit so the drawer is accessible again. Who am I kidding--I don't use drawers, I just leave stuff in piles. Ha!

    I had a few copper fittings left over from a plumbing project that fit the pillow block fairly well. The bearing has a few set screws that I was able to tighten securely; the shaft rotation isn't very centered, but I just needed a relatively low-friction pivot point that was also quite rigid. This definitely fits the bill:

    It's fun to do a bit of 'big kid soldering' after playing around with 0402 resistors. The pillow block rides on a slip coupling fit over 1/2" copper pipe; one of the elbows is just dry fitted so I can pull the bearing out. Also, I didn't want to sweat pipes around the bearing.

    So! FINALLY ready for the next round of thrust tests! My wife and I are headed to the Bay Area through 10/19 for a conference and a vacation; with luck, I'll be able to play around with motor cooling and fan ducts before the end of October. Stay tuned!


  • Back to work!

    zakqwy09/27/2014 at 01:56 2 comments

    I didn't realize how much of a sprint I was in leading up to the Hackaday Prize Phase 1 submission deadline. Looking back through the project, it's a bit nuts to see how many log updates I put together in July and August. The break has given me a bit of time to work on some house projects; they aren't wrapped up in the least, but I'm ready to start balancing them with GimbalBot again. The lack of deadline means this balance will likely be a bit more sustainable. 

    Not much has happened in the way of design progress (at least outside of my head) or construction since the run up to August 20th. However, a few key items have been added to my shelves.

    First of all, the venturi tubes (I think this is a more correct name) and motor ducts arrived. They look great; no obvious voids or flaws beyond the duct not fitting the curvature of the motor perfectly. I may add a thin layer of RTV (or some type of form-in-place gasket material) to the end of the ducts so they seal up well against the motor base. I'm particularly happy with the smoothness of the venturi tube curves; I'll probably use the pieces as-is without any sanding, at least for initial testing. The accuracy spec on the material is +/- 0.15mm (I'm guessing the build height is something like this, or maybe 0.1mm), so I expected pretty good results. 

    Most importantly, the venturi tube width appears to be right for a tight fit in the slots I'll cut in the square tube stock:

    I should be able to leave a ~0.5mm lip at the bottom of the square tube slots to hold the venturi tubes in place, at least for testing purposes.

    Something else has been added to the collection as well. Something I'm quite excited about.

    Without getting into too much detail, I get to work with some pretty interesting stuff. My employer sells various bits of industrial equipment--valves, instruments, pumps, etc--that are all amazingly engineered and meticulously crafted, but typically far outside the budget for a personal project. When I started a bit more than four years ago, an item we previously worked with caught my eye in the warehouse. I noted its location and continued to watch it.

    It's the radio control belt pack and receiver for an extremely large piece of mobile outdoor industrial equipment. These devices were engineered-to-order; while the radio circuitry and basic configuration options (dual analog joysticks, E-stop, enclosure, etc) were standardized across the product line, we provided the systems with a customized set of switches and knobs along with a beefy Amphenol connector for easy integration into existing equipment. My boss gave it to me when I offered to buy it. Awesome!

    I'm excited about this platform because the hardware is ridiculously awesome. The belt pack is designed to work year-round outside in Minnesota; the switches all have rubber sealed boots, and the joysticks are extremely rugged. While the first course of action is clearly to take it apart, my basic plan is to update the RF and I/O guts to make it more suitable for GimbalBot. The receiver weighs a few pounds and communicates via Modbus over RS485; a great protocol if you need to go far in a noisy environment, but I need something that weighs fifty grams or less (I'm guessing the connector alone would exceed that).

    Unlike some of my other hack-apart-and-sorta-fix-up projects, I want to do this one right. I don't want to add any new penetrations to the transmitter's enclosure, allowing me to comfortably maintain its environmental protection capability. Realistically, I could see installing a few heavy-duty bulkhead connectors for things like an external antenna. 

    The cross bar--in addition to acting like stool legs when you flip the entire unit upside-down to use as a chair--would make a great mount for an FPV monitor. Other than that, I want to keep all the modifications internal and ideally use the existing battery compartment for its original purpose. I'm hoping that the internal switch connections use screw terminals, so...

    Read more »

  • Project Morpheus

    zakqwy09/03/2014 at 00:46 2 comments

    During a conversation earlier today, Arsenio Dev mentioned Project Morpheus. I recall occasionally seeing videos of the vehicle online in the last few years, but I hadn't closely followed its progress over the last few months. He recommended that I take a look at some of the videos related to tethered testing. I'm glad I did:

    First of all, the music is amazing. Secondly, if you fast-forward to 2:10 or so (although you should really watch the whole thing), you'll see the test craft suspended from an overhead crane and anchored at four points to the ground. It's a great setup; the craft is constrained in all axes but still free to apply forces to the cables. I think a setup like this could be ideal for early GimbalBot tests, as I could insert gradual amounts of cable slack as the control algorithms improve. Maybe I could use a series of cheap spring-loaded scales to characterized the thrust vector produced by the craft. Either way, I'm still starting with static (fully constrained) tests.

    Time to go watch more Morpheus videos; the archive is quite awesome indeed. 3D printed parts shipped today, so we're on schedule to start crudely instrumented experiments shortly.

View all 70 project logs

Enjoy this project?



Gabriel wrote 04/14/2016 at 22:29 point

Does this thing fly yet?

  Are you sure? yes | no

zakqwy wrote 08/28/2016 at 14:56 point

:-( nah, it still collects dust

  Are you sure? yes | no

Gabriel wrote 09/07/2015 at 21:30 point

Does this thing fly yet?

  Are you sure? yes | no

zakqwy wrote 09/08/2015 at 16:26 point

Ha! No. You'll be the first to know. This project is currently shelved.

  Are you sure? yes | no

Rob Parzek wrote 09/04/2015 at 14:41 point

This thing is epic and I hope you get to dive back into it once the smoke clears! 

  Are you sure? yes | no

zakqwy wrote 09/04/2015 at 14:44 point

Hahaha thanks! It's been hanging on my basement wall pretty much since the last video, but I'll surely get back to it at some point.

  Are you sure? yes | no

Gabriel wrote 06/03/2015 at 20:46 point

Does this thing fly yet?

  Are you sure? yes | no

zakqwy wrote 06/03/2015 at 21:08 point

Sadly no progress on GimbalBot since the last video. Next step is (still) putting a 220vac drop in my basement to run the shore power setup.

  Are you sure? yes | no

Jarrett wrote 06/03/2015 at 21:33 point

So any day now, right? ;)

  Are you sure? yes | no

Gabriel wrote 01/26/2015 at 20:50 point

Does this thing fly yet?

  Are you sure? yes | no

zakqwy wrote 01/26/2015 at 20:59 point

Ha! Fair question--no. I've thought about throwing caution to the wind and skipping the thermal stuff, but I want to improve motor cooling a bit before any tethered tests happen.

  Are you sure? yes | no

Gabriel wrote 01/28/2015 at 18:45 point

you seem to suffer from "it has to be perfect" syndrome.... The main symptom is unfinished projects, and later personally becoming a ghost.

I was diagnosed myself with it years ago.

Fly the thing already!

  Are you sure? yes | no

zakqwy wrote 01/28/2015 at 20:45 point

Man, you're totally right. You should see my project car, it's years away from the road and has been for... years.

Commitment time--my next log update will occur by the end of the weekend, and will include a video of GimbalBot's first tethered flight.

  Are you sure? yes | no

slartibartfast wrote 10/20/2014 at 15:38 point
I'm blown away by your project! I am currently studying Linear Controls and Systems, so when I first saw your project, I was mind-boggled as to what state space decomposition required for your crazy machine would be. Have you ever tried this line of thinking?
Awesome project, and when it finally flies, I bet it'll be a sight to behold!

  Are you sure? yes | no

zakqwy wrote 10/20/2014 at 18:28 point
Thanks for the kind words! I'm afraid I don't know a great deal about state space decomposition (okay, I don't know _anything_ about it), so I haven't tried that method before. I picked up Peter Maybeck's 'Stochastic Models, Estimation and Control: Volume 1' a few months ago and started picking my way through it, but I haven't applied anything I've [barely] learned to GimbalBot. Generally speaking, my philosophy for this iteration of the project has been 'get it off the ground, then think about controls'.

Any ideas? I welcome all input, especially tied in with a learning opportunity! How would you model this system [and validate said model]?

  Are you sure? yes | no

slartibartfast wrote 10/23/2014 at 15:22 point
I don't think I've reached the stage where I can apply it to actual physical systems yet, but if and when I do, I'll be sure to try it on your contraption and let you know what falls out of all the equations.
Are you testing it initially with the battery arm hanging below the propulsion portion? That should be easier I guess due to the center of gravity assisting in the stability.
PS: I think SpaceX's Grasshopper rocket will have similar dynamics as it has a single point of thrust which it needs to manipulate to get it to float around in the right way. Although your GimbalBot will have much more directional authority due to ability to pivot the motors to a greater extent. But with great maneuverability comes great instability (lame spiderman ripoff)?


  Are you sure? yes | no

Stryker295 wrote 09/12/2014 at 12:17 point
Ooh! As someone who's worked on a huge set of balancing devices and systems, including a miniaturized (successful) replica of MIT's Ballbot, I absolutely loved reading about this project.

I'm left with a question/concern, though, as someone who's never had the opportunity to work with flying-balancing machines.

I presume that if something, say, a hovering quadcopter, dropper in the air suddenly, the motors would kick in with extra oomph to try and compensate, thus maintaining position. However, if one of your propellers breaks due to stress from rotating in 2-3 dimensions, (in my mind) the system would speed up to try and compensate for the sudden lack of thrust.

But, if a prop has broke on ya, it'd make sense to me to shut things down instead of kick 'em into high gear. Do you have any planning for this sort of circumstance?

I've never worked with the hardware and software of flying machines, just hardware, so I'm definitely not as educated as you'd be on this matter, I just wanted to ask!

  Are you sure? yes | no

zakqwy wrote 09/12/2014 at 13:22 point
Hey! Glad you found the project. I'd like to see more information on your Ballbot replica; there aren't a ton of them floating around on the 'net, so any more data points I can look at would be fantastically helpful. If you're willing to share code, I'd buy you a beer if you ever make it to Mpls.

You're dead on with regard to a failed prop. With any luck, the CFRP ducting, motor cooling system, and larger batteries will push my maximum safe thrust:weight ratio into the 1.3-1.5:1 range; however, losing a prop would not be a recoverable scenario. Worse, I'd completely lose yaw control, so the vehicle would plummet to earth while spinning at a rate related to the RPM of the remaining good prop.

Based on playing around with the props a bit, I'm guessing a motor or ESC failure is more likely as the props are quite strong and light (I've wrapped my curtain around them enough times to be confident in their structural integrity). Either way, I'm planning to have some kind of emergency function running that shuts down both brushless motors if the instruments detect a dramatic thrust or RPM anomaly. If GimbalBot is going to crash to earth, shutting everything down before impact will probably reduce the extent of damage and make it safer to approach for recovery.

Side note--this comment is a great excuse to explain the lack of recent progress. In a nutshell, my other big project is my house. Right now my wife and I have the second floor torn down to the studs with a few massive holes waiting for windows. I live in MN, and we're looking at lows in the high 30s (F) tonight. The recent cold snap pushed us into high gear to get the exterior buttoned up and insulation in place before winter. Never fear--tests will continue in a week or two, so stay tuned.

  Are you sure? yes | no

Tachyon wrote 09/13/2014 at 11:08 point
My first thought in reading this comment was to set the system up so that if it detects this scenario, to kill all the motors and deploy a parachute. The hobby rocket industry has plenty of cheap, simple, reliable, and electronically activated solutions for this.

  Are you sure? yes | no

Peter McCloud wrote 08/21/2014 at 03:09 point
The updates you've made to you page look great! I'm also impressed with the side by side photo with the CAD and real life Gimbalbot. Great job!

  Are you sure? yes | no

zakqwy wrote 08/21/2014 at 03:11 point
Thanks Peter! I'm excited to have most of the physical construction done. Time to get this thing in the air!

  Are you sure? yes | no

curtis.layton wrote 08/06/2014 at 00:50 point
Hi Zach!

I just watched your "first twitches" video and I have a quick suggestion. Insert a large-ish value capacitor close to the servo power leads (right at the servo connectors). This may negate your need for a higher current bench supply as your servos are probably only intermittently drawing a lot of current.

  Are you sure? yes | no

zakqwy wrote 08/06/2014 at 02:24 point
Excellent call, Curtis. I just ran a few more tests off a different supply, but I'll definitely do that prior to servo tests under load. Any recommendations on value? A thousand uF? I suppose that depends on the magnitude of the servo current demand..

  Are you sure? yes | no

davedarko wrote 08/02/2014 at 15:35 point
Are those pictures supposed to be inverted?

  Are you sure? yes | no

zakqwy wrote 08/02/2014 at 19:34 point
Nope. The colors are good on my computer and phone; are they showing up inverted for you?

  Are you sure? yes | no

davedarko wrote 08/02/2014 at 20:17 point
Tried to get a working and not working thing on there. The latest log shows all pictures inverted on my tablet..

  Are you sure? yes | no

zakqwy wrote 08/02/2014 at 22:39 point
Wow, that's super bizarre. I'll post it to the Feedback section. Thanks Dave!

  Are you sure? yes | no

davedarko wrote 08/02/2014 at 22:46 point
They are fine on my mobile strangely..

  Are you sure? yes | no

jlbrian7 wrote 08/01/2014 at 17:37 point
i would like to build an rov with this type of thruster setup

  Are you sure? yes | no

zakqwy wrote 08/01/2014 at 17:49 point
That would be pretty wicked. Keeping the motors watertight might give you some trouble but I'm sure it's doable.

  Are you sure? yes | no

jlbrian7 wrote 08/01/2014 at 17:55 point
its not so different from the thruster hackaday did a write up on. you just need a brushless dc motor stator, and core with no shaft. design a housing for the stator and a shaft, and oil fill it.

i bought a few books on casting aluminum and i have a small sherline mill... maybe one of these day.

  Are you sure? yes | no

Sugapes wrote 07/20/2014 at 10:27 point
Very cool project! It reminded me of this quote by JFK (space theme and everything): “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard."

  Are you sure? yes | no

zakqwy wrote 07/20/2014 at 12:37 point
Agreed. GimbalBot is about doing things the hard way. Great quote!

  Are you sure? yes | no

Andy Z wrote 06/21/2014 at 14:09 point
Love the project Zach! Very thorough write up on a fantastic idea. Your projects have come a long way since the neon tube light saber :)

  Are you sure? yes | no

zakqwy wrote 06/21/2014 at 19:06 point
ANDY!!! Great to have you on here. Thanks for following the project! Man, we would have had some fun if high wattage brushless motors were commonplace in the late 90s. These things are serious business!

You should probably build a quadrotor, if you haven't already. Totally up your alley.

  Are you sure? yes | no

frankstripod wrote 06/09/2014 at 07:46 point
Are you still considering X/Y axis vs Polar gimbal? It's like a cliffhanger for me. Also, on the first thrust test video (awesome), do the motors bend away from each other at higher speeds, or am I just seeing things on the axis where the prop nuts almost meet?

  Are you sure? yes | no

zakqwy wrote 06/09/2014 at 12:44 point
I flippy flopped a few times back and forth, but at this point I still want to make the polar gimbal work. It's a novel design, and the outer rings act as safety cages around the propellers--something I'd need to incorporate regardless.

You're right about the motors bending apart a bit, but they also aren't perfectly aligned to start with (blame my sub-par home manufacturing skillz). I expected a fair amount of deflection, as the CFRP motor support plate is only 1/16" thick. This setup is kind of a torture test for the plate and glue joint; I plan to make the actual motor mounts a bit more beefy in the first full prototype.

  Are you sure? yes | no

frankstripod wrote 06/09/2014 at 17:23 point
I am imagining the further they twist off axis more power is lost to turbulence. I am hoping your beefyness will bump up your thrust a little. I would like to see results of a beefier video if you do more testing.

  Are you sure? yes | no

frankstripod wrote 06/09/2014 at 17:26 point
I am happy your sticking to your guns on the original gimbal. I didn't want to be the troll who says “you know what you should do...”, making all projects similar and boring. Its awesome do to unique design! That being said, sorry for the following: I'm thinking the 74g power inverter will throw off the balance of the gimbal assembly making it slower and (also with the weight) more power consuming. In my head, I imagine the inner gimbal mounting plate being symmetrically distributed with parts for perfect balance. Tell me I'm wrong and the power loss is insignificant.

  Are you sure? yes | no

zakqwy wrote 06/09/2014 at 19:11 point
I might reinforce the existing test rig to get it closer to the final design, but I probably won't rebuild the mount at this point; CFRP isn't cheap.

You're on the right track with the invertee. Efficiency isn't a huge concern as the GE device I selected is rated at 96-97%; extra weight on the motor plate is a bummer though, especially since it's offset. There's an analog to the automotive world here--unsprung weight is the worst kind.

I'm on the road early this week but when I return I plan to start a v07 CAD model. As I aluded to in my comment to Hank, I want to explore using the top-mounted battery as a reaction wheel.

If you're still concerned about me dumping the polar gimbal design, maybe this will set your mind at ease a bit: I ordered four 4-cell LiPo packs, a 4 gang charger, and a Moog slip ring last night. I'm now officially invested in rho.

  Are you sure? yes | no

frankstripod wrote 06/09/2014 at 19:45 point
Thank you for the replies :) I really like the reaction wheel idea.

  Are you sure? yes | no

zakqwy wrote 06/09/2014 at 03:00 point
To keep it all in one place, I got this comment on a recent facebook post: "What's your target weight, and what power ratio are you hoping for? I'm curious how far out of vertical the fans will have to point to navigate and stabilize, and how that will affect vertical thrust. Also I'm curious what effect two facing blades has vs side-by-side mounting... the turbulence must do something wonky, no? (sorry, couldn't figure out how to comment on the project page.)"

  Are you sure? yes | no

zakqwy wrote 06/09/2014 at 03:01 point
(My reply copied from FB): You should make an account on HaD! Commenting is pretty easy. Briefly, I want a power::weight ratio between 1.2 and 1.5 while ideally getting at least ten minutes of runtime. The BOM spreadsheet gets into detail on the weight, but if the thrust can't get any higher then I'll need to keep the weight between 1.0 and 1.2 kg. I haven't taken the time to calculate actuation speed, angle, and torque for theta or rho control, but I can adjust rangability vs torque/speed by swapping out linkages for theta; for rho, I'm getting the highest performance servo I can find that doesn't weigh too much. I couldn't find a quick way to determime thrust loss due to the contra-rotating design, hence the test rig--right now it appears to be fairly severe, as a single prop hit 1070g in earlier tests. I didn't measure current though, and there's a good chance my supply was pegged at 360W.

Let's continue this convo on the site page?

  Are you sure? yes | no

hank.butitta wrote 06/09/2014 at 03:46 point
Well, now you have me reading about coaxial rotors on the internet, trying to see if there's a straightforward answer to how it affects lift (didn't find one) instead of the stuff I'm supposed to do (but clearly have little interest in doing :)

After reading some of your posts, the slip ring does sound like a bit of a hassle. (side note, "shower concerns" made me think of, I'm sure you'd enjoy it there.) Looking at your drawings, I see the slip ring is between the pitch ring and CFRP frame. I guess I don't understand why the pitch ring exists? Would it be possible to nix the pitch ring and simply rotate the entire frame using the third option in your shower concerns: "Correct for the frame rotation by modulating the relative propeller speed. This would essentially add a layer to the motor speed control loop, taking another input from the IMU system."

Hell, if that's too slow or complicated, could you eliminate the pitch ring and control Rho with the equivalent of a tail rotor on the CFRP frame?

  Are you sure? yes | no

hank.butitta wrote 06/09/2014 at 03:52 point
Follow up thought: From what I can tell, the whole point of the pitch ring is to allow the primary frame to be free of Rho rotation. Is this important to you? Do you want to be able to control the direction it "faces", or is maneuverability the only concern? Without passengers or cameras (camera would probably add too much weight?) I'm not seeing an immediate advantage to keeping the frame facing a certain direction.

  Are you sure? yes | no

zakqwy wrote 06/09/2014 at 13:00 point
You should be careful, Hank; is a great source of productivity avoidance. A lot of the projects (such as the DIY Raman spectrometer) can suck you in to hours of background research.

My concern about using relative propeller speed for rho control is that the propeller rotational axis won't always be in line with GimbalBot's center of gravity; since the CG is going to be partway up the frame above the thruster, any theta angle will mean this type of rotation will also impart an unwanted torque around the CG that I'd need to compensate for in the control scheme (and since the angular offset between the thrust vector and the longitudinal axis varies depending on theta, the torque magnitude would probably vary). Still might be something that could work and be corrected in software, but depending on that too much makes me nervous.

I nixed tail rotors and non-coaxial propellers early on in the interest of radial symmetry. It's a bit of an arbitrary constraint that falls under the 'impractical but looks cool' category.

I do want to keep the frame facing a certain direction; at some point, adding peripheral devices to the GimbalBot frame will be important. Even without extra sensors (such as cameras), I'd like to be able to fully control orientation.

Great comments, Hank. One thing you've made me think about more (mainly by trying to figure out ways to avoid it) is how much extra complexity the rho axis adds to the design. In addition to adding to GimbalBot's width (possibly forcing me in to a more expensive sheet of CFRP) and requiring the expensive/heavy slip ring/converter subsystem, I'm also concerned about basic stuff like shaft alignment and bearing design.

Here's an idea to mull over a bit: what if I nix rho control on the pitch ring and just do theta control to the thruster, and design a reaction wheel that uses the top-mounted battery pack as a rotating mass? Advantages: (1) moves a lot of mass off the gimbal assembly, (2) moves a bit of mass further away from the thruster which will raise CG, (3) eliminates need to rotate the thruster, so I can dispense with the pitch ring, and (4) is kinda cool? I'd still need to use the converter and slip ring, but it'd be much easier to implement since I'd have a lot more room.

I might throw that in to a CAD model this week and post another update. Keep the suggestions coming!

  Are you sure? yes | no

hank.butitta wrote 06/09/2014 at 23:29 point
Ha! I love the idea to use the batteries as the mass for a reaction wheel. It's fun and ridiculous.

I'll have to check out your next CAD model to fully understand what you're thinking, but it sounds like you're suggesting the slip ring is for the battery-pack/reaction-wheel, and in order to control Rho, the whole rig has to turn? So, you can control direction, but you couldn't necessarily choose to look in one direction while doing other maneuvers?

Also, I'm so used to thinking "high CG is bad" that I forgot to consider it could be useful/necessary in this case. I'm thinking about balancing long objects on my palm, and the taller an object is, the easier is to balance. I can make larger inputs at the bottom without disturbing the top as much. It just seems more stable, less finnicky.

Is the ideal for this design to have the CG as high as possible?

  Are you sure? yes | no

hank.butitta wrote 06/09/2014 at 23:43 point
Also, I know you already bought a slip ring, but you don't have to give up radial symmetry to use axial rotors... just use two tiny ones! It's not as cool as spinning battery packs, but will probably get the job done.

Oh, and another maneuverability question: how are you imagining the controls work? I'm imagining manual control for thrust, Rho, and Theta, but on top of your inputs the software will have to compensate to keep the thing balanced. Do any of the "ball bots" have code you're able to steal as a starting point?

  Are you sure? yes | no

zakqwy wrote 06/10/2014 at 00:49 point
Watch the page for updates. I'm guessing the next log update will be later this week (provided I have time in the evening to work on the model, I'm in Brookings tonight away from my CAD machine). I think SW can open Cubify Design files; let me know if you have any issues and I'll see if I can export 'em to another format.

You're correct on CG vs CT. I'm guessing that's why Goddard's original design ended up with some modifications ( ). I never got around to finishing v06, but I actually intended the rho servo to be mounted high with a long CFRP shaft for actuation--all in the name of raising the CG a bit. Higher center of gravity is good for stability, as you can test by balancing a yardstick on your hand then balancing the same yardstick with a glass flipped over on top of it. Note: I'm not responsible if you break a glass. Wear safety goggles.

For now, I might give up the goal of maintaining craft orientation during maneuvers; even with the v06 rho control design (i.e. spinning a pitch ring), the craft will counter-rotate by some amount proportional to the ratio of the two inertial masses--either way, I'll have to deal with it somehow. Using a reaction wheel (that happens to be made out of the heaviest part of the design, the batteries) just takes advantage of this property.

Tiny propellers lose thrust pretty fast. Check out the thrust calculator I posted some time ago; try changing diameters and see how things work out. I'm guessing a pair of 4" props comes nowhere near the thrust of an 8" prop without crazy fast RPMs. Also, symmetry!

Control is something I've thought about quite a bit and will probably have to think about quite a bit more. The ballbots I've checked out don't have publicly available code (unless CMU decides to be generous); a good starting point will be understanding the inverted pendulum problem which is well documented online and elsewhere. I've put off brushing up on my Newtonian mechanics, but I see a lot of free body diagrams in my future. Either way, my ultimate goal for control abstracts raw theta/rho/thrust/differential prop RPM in several discrete layers. I'll get in to detail on my initial thoughts in a future post (probably while I'm waiting for prototype parts and don't have anything to write logs about); in the meantime, I'd love to hear your ideas. I'm certainly not short on processing power with an ARM Cortex M4.

  Are you sure? yes | no

Michael O'Brien wrote 06/08/2014 at 20:08 point
Well, it'll fly with that thrust so I think you might want to change the description to "it might work" ;)

  Are you sure? yes | no

zakqwy wrote 06/08/2014 at 21:16 point
An excellent point. Fixed!

  Are you sure? yes | no

Mike Szczys wrote 06/06/2014 at 23:11 point
Thanks for entering this one in The Hackaday Prize.

I'm glad you decided to share you work as it progresses. Personally I find that I finish more of my projects if I document them along the way because it's a way to figure out what I need to do to get started again after a long lapse in working on it. Good luck!

  Are you sure? yes | no

zakqwy wrote 06/07/2014 at 00:03 point
Agreed on the documentation. It's always disheartening to dig up an old project and be forced to reverse engineer your own work.

By the way--not sure if you saw it, but I posted a message to you on .Stack.

  Are you sure? yes | no

Jefito wrote 05/21/2014 at 16:20 point
For all sorts of mechanical design info, a great site is:

  Are you sure? yes | no

Jefito wrote 05/21/2014 at 04:01 point
What are your thoughts on cantilevering the two motor/blade pairs? With this setup, vibration could cause issues. If you hit a natural frequency with the motors, it will rip itself apart. Going stiffer would be tough, but you could add a bushing above or below the blade to reduce your wagging mass.

  Are you sure? yes | no

zakqwy wrote 05/21/2014 at 12:39 point
Cantilevering the motors out to the side? One constraint I'm (sort of) designing around right now is stock Dragonplate sizing; ideally, I'll be able to waterjet the motor plate and pitch ring out of the same piece of 1.6mm stock, and I think 12"x12" is a standard dimension (which I'm right up against on the pitch ring).

Can you napkin-sketch and post your thoughts? I'm having a bit of trouble visualizing the concept.

  Are you sure? yes | no

Jefito wrote 05/21/2014 at 03:51 point
I was trying to poke around the CAD. Is there a top level assembly? I could only see the subassemblies...

  Are you sure? yes | no

zakqwy wrote 05/21/2014 at 12:21 point
Yup, it's in v06/Assemblies. I ditched subassemblies at some point because Cubify Design makes subassembly parts static when added to assemblies.

  Are you sure? yes | no

zakqwy wrote 05/21/2014 at 12:36 point
I should be more precise: that folder has five assemblies in it that I've been building up as 'subversions'. Check MotorBracketPropsPlateRing, that's the latest. Let me know if the format gives you issues.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates