Tau Labs Sparky: new Tau Labs flight and brushless gimbal controller

So I've been working on a small board for Tau Labs called Sparky, which I wanted to share.

View attachment 11995

The goal was a small single sided board that was relatively easy to hand assemble. It has a gyro / accel / mag / baro and does altitude hold, position hold, rth, etc.

There is also an add-on board for it which lets it drive a brushless gimbal. I took it out on the beach today and got some (I think) pretty nice video.


Since this was sailing weather, obviously the wind was quite choppy. There is a scene in there which compares two go pros - one on the gimbal and one fixed (for FPV) so you can see how much small movement it was suppressing. Sparky (and the other Tau Labs targets) can also output a mavlink stream which can be fed into a mimimosd, which you can see above. I've also tested it on a larger gimbal from AGLHobbies with a Sony HX9V, although that needs more tuning


finally here is a set of clips trying it out on various frames (including a dual front motor tilt-rotor)

I have other notes about it over on my blog http://buildandcrash.blogspot.com/ and https://groups.google.com/d/msg/phoenixpilot/Yw-1yUFcoiE/O80P1omQKNMJ

All this filming boats has me really wanting to make a small GPS + Radio module that it can chase after. Follow me for a tablet is already supported though, but I think a module would be better if the pilot is standing on the shore during this.
 

Attachments

  • Screen Shot 2013-05-26 at 12.25.21 AM.jpg
    Screen Shot 2013-05-26 at 12.25.21 AM.jpg
    19.9 KB · Views: 448
Last edited by a moderator:

DennyR

Active Member
James
Nice to see you getting involved with the Brushless craze. Looks like with the small board you have the IMU integral?
 

Yeah, it's integrated. Actually it doesn't have to be - the driver board is designed as a separate board but it solders on the back of Sparky to appear like one board.
 

I have the gimbal controller talking to the flight controller now, so it can use a brushless gimbal controller to fix on certain coordinates. Basically it takes the current GPS coordinates and the desired fix location and calculates the bearing and declination to the target. The bearing sets the quad's yaw and the declination the camera pitch. Initial testing worked fairly well.


The next step is to have the location be streamed from a phone/tablet. The code is already done but just needs me to talk the g/f into being a test subject.
 
Last edited by a moderator:



Bartman

Welcome to MultiRotorForums.com!!
James,
Congrats on the new releases, the videos look good!

Have you ever considered making the camera control predictive so it is factoring in what is coming from the control/radio to anticipate movements while also reacting to the actions of the helicopter itself? Maybe 30% predictive and 70% reactive?

You're the only guy I know with the control of code and electrons to answer the question intelligently! Thanks in advance.

Bart
 

James,
Congrats on the new releases, the videos look good!

Have you ever considered making the camera control predictive so it is factoring in what is coming from the control/radio to anticipate movements while also reacting to the actions of the helicopter itself? Maybe 30% predictive and 70% reactive?

You're the only guy I know with the control of code and electrons to answer the question intelligently! Thanks in advance.

Bart

Yeah, it has definitely crossed my mind. If you look at how I designed my gimbal controller:
http://buildandcrash.blogspot.com/2013/05/sparky-brushless-gimbal-controller.htmly
you'll see that it uses CAN to communicate between the FC and BGC. The benefit of that is that it is high speed and bidirectional to allow things like this. For example if you account for the relative attitude of the two boards you can predict with the fact that the roll axis stops being pure roll when the FC is pitching forward.

I mostly intended this for doing this like dialing in a set attitude or doing POI tracking. However, I haven't actually tried to create a feedforward correction term. When I got this video, I concluded that things were working pretty well and started playing on other things

Now if you think about it - the gimbal basically has to deal with two sources of movement. 1) your control inputs and 2) external undesired disturbances. The FC knows about both 1 and 2. The feels 1 and 2 the same. I'm not convinced trying to pass information regarding #2 to the BGC would be helpful. The FC already is doing its best to suppress any undesired movements and what it fails to suppress gets to the BGC, which can measure them itself pretty accurately (more below). However there might be some benefits to passing #1 through.

I think there would be a pretty simple way to tell if this would benefit you. First take some video on a fairly breezy day and try and put in as little stick input as possible. Look how much movement there is. Now start hauling on the sticks and compare that. If you have pretty good suppression when you are moving the sticks it might not be worth the trouble.

---------

Regarding suppressing disturbances I think it would take some modeling to be 100% sure how beneficial it might be and how to use that information. I'm thinking out loud here.
1. The airframe feels a torque disturbance which it measures with its gyros and fairly quickly tries to suppress. The end result is that the scale of the rotation on the gyro is reduced (but not eliminated) by the FC. We can call this theta_1.
2. That residual rotation is transmitted to the gimbal mount. It measures the beginning of theta_1 and quickly tries to compensate. You get some reduced movement theta_2 based on the feedback gains on the BGC controller.

So actually thinking it through more formally, I can see theoretical benefits for applying a feedforward component for theta_1. Then the feedback controller on the BGC is only dealing with the residual error which would hopefully be less than theta_1. There are quite probably practical issues that 1) you will have noise in the feedforward theta_1 so you need to find the best filtering to apply and 2) tuning it and keeping it stable.

Next time I play with my gimbal I might give that a shot.
 
Last edited by a moderator:

Bartman

Welcome to MultiRotorForums.com!!
thanks for the quick and thoughtful reply James. we're down to the gnat's *** here as far as how much more improvement can be made. i've just figured that the next big improvement might come from the gimbal being forewarned as to what is happening at my thumbs. there's a big opportunity there to know what's coming and to cut response time a little more by letting the gimbal anticipate changes. a little extra torque to help a brushless controller gird itself for an intentional move of the helicopter might be a benefit. after you master this we'll need sensors in the brain (heading upstream of the thumbs in the control process) to grab the next big performance improvement.

Enjoy your holiday and looking forward to what you can do next!
 

after you master this we'll need sensors in the brain (heading upstream of the thumbs in the control process) to grab the next big performance improvement.

I'm already working on [video]http://buildandcrash.blogspot.com/2013/12/eeg-design-time-for-something-totally.html[/video]
Screen+Shot+2013-12-15+at+2.54.44+PM.png
 



Last edited by a moderator:


birdmanpete

New Member
I have just flown my Sparky. Beautiful, thankyou. The next step for me is to add GPS. (if I can) Where will I find a description of that process ?
Birdmanpete.
 

Top