148 replies to this topic

[jes1111]

Correct me if I'm wrong, but that demo is not doing anything "camera specific" - it's using an IMU (with MARG-flavoured mathematics) to compute sensor attitude and feeding the servos with the inverse on each axis: the equivalent, if you like, of using a gimbal-dedicated CC.

What it does demonstrate is what I was saying about the rigidity and particularly the speed of the gimbal - look at the lag on this video.

How about this for an example of beautiful mechanical design - no less than I would expect from Gitzo, who make the finest photographic tripods. You gotta love the description of it from their website:

Quote

This head gives support to the expressive capacity of photographers by allowing them to continually renew their inventive creativity and achieve hitherto unimaginable results.

Pity it weighs 3kg, though

[RobCC]

Yes , that is  camera specific should be an additional CI gyro / acc positioned on the camera support with independent calculation of attitude.

[jes1111]

I meant that the calculations performed are not specific to controlling a camera - they are the same calculations as are performed for a flight controller. I thought about using a dedicated gimbal controller but actually I can't see any point - in fact, it just makes your life more difficult as you would then have two sets of calibrations to perform and no way of knowing if the frame's idea of "level" was the same as the gimbal's idea of "level".

[RobCC]

My interest was in the algorithm MARG is that it is inexpensive in computation.
It can be used a small 48 MHz CPU for example. (Or CC if have memory/computation problems ...)
I tried with an F342/48Mhz with a period of 1 mS and it is OK.

How about a small independent CI CPU equipped with Gyro + ACC + RF + 4 / 6 PWM outputs.
That could be placed directly on the camera (its important to place sensors here) and drive / stabilize it.
That communicate with the mothercard OPenPilot Pro version ...X  equipped with  RF 1mW or Bluetooth

I think that the project is useful and it will be able to communicate with other tools such independent articulated arm, winch .....
we must therefore think fit OpenPilot Pro component RF low power ...

Google traduct ...

[peabody124]

RobCC, on 27 June 2011 - 08:16 AM, said:

There is a specific example of use MARG here:camera
But I feel the vibrations arent "mechanical" (flexible support may be ?)

No they are.  Compare the video at the end which loops pretty much perfect when not flying.

A second board could work, but the question is why do it if it's not needed?  Whole new can of worms there - sending over commands and such.  But it's easy to do, just put it on there stock and ask it to do self leveling through servo mechanism.  The right mixer and it would just use our CF to estimate attitude and drive it to 0.

[jes1111]

peabody124, on 27 June 2011 - 12:31 PM, said:

No they are.  Compare the video at the end which loops pretty much perfect when not flying.

A second board could work, but the question is why do it if it's not needed?  Whole new can of worms there - sending over commands and such.  But it's easy to do, just put it on there stock and ask it to do self leveling through servo mechanism.  The right mixer and it would just use our CF to estimate attitude and drive it to 0.

I thought about a cooperative arrangement between a CC and gimbal-dedicated CC (or anything else) - but I believe one of the most important aspects is speed, i.e. once the craft's attitude is computed you want to be driving the servos to the corresponding (inverse) position as soon as possible (and as quickly as possible). Any additional computation or re-computation is just going to introduce more lag, putting you even further "behind the game".  So I agree with James - CC can give you the info you need to drive the gimbal - so use it!

Are you expecting Pro/INS to be "better" in this respect? i.e. will the attitude estimation be quicker, more accurate, etc.?

[jes1111]

Incidentally, just for reference - high-end gimbal specs seem to be around 200 degrees/second rotation on each axis and 0.05 degrees (or better) "positional accuracy".

[RobCC]

You do not think it would be interesting to place the sensors closer to the center of rotation of the tool ?
If so, we must put them on a separate card with no wire ...

[peabody124]

Yeah the attitude estimation of the pro is better.  It has the additional information (baro, mag, gps) and fuses it all in one filter which gives a more precise attitude.  That being said while hovering to take images that becomes much less of an advantage.  The pro has more spare horses too so can run fancier algorithms for camera - but I'd like to see a demonstrated need.

As for locating the sensor on camera, I don't think that's useful.  At any reasonable range the different offset is irrelevant, only the angle matters which is preserved for a rigid body rotation.

[importon]

Awesome!  can't wait to use this!

peabody124, on 26 June 2011 - 04:54 AM, said:

I updated the video at the start of thread.  Putting here so people don't have to click back though.  First Pan/Tilt flight on CopterControl or OpenPilot .  My first milestone in ages!  



I should comment that the mount itself allowed a lot of vibration which is apparent.  However it's pretty obvious that while I was flying around with a lot of angle there wasn't any pan tilt error to speak of.

[nikivan]

peabody124, on 27 June 2011 - 02:27 PM, said:

... - but I'd like to see a demonstrated need...

A separate board for stabilizing the camera is needed when using 360-degree gimbal. I'd like to see a dedicated version of CC FW just for that purpose.

Cheers,
Nick

[jes1111]

nikivan, on 04 July 2011 - 05:06 AM, said:

A separate board for stabilizing the camera is needed when using 360-degree gimbal. I'd like to see a dedicated version of CC FW just for that purpose.

Cheers,
Nick

Hi Nick,

Could you explain what you mean here by "360-degree gimbal"?

For a gimbal-dedicated CC - what functions would you like to see?

Jeremy

[peabody124]

It's no help for me saying things like "I'd like to see a dedicated version of CC FW just for that purpose."  I need to hear clear design requirements.

[Naterpin]

peabody124, on 05 July 2011 - 03:21 AM, said:

It's no help for me saying things like "I'd like to see a dedicated version of CC FW just for that purpose."  I need to hear clear design requirements.

Thank you for doing all this work. I am interested in see Camera Stabilization for the CC too.

As for design requirements I would be happy to 2 axis. for my Hex
Once again thank you for doing this work.

[Berkely]

peabody124, on 05 July 2011 - 03:21 AM, said:

It's no help for me saying things like "I'd like to see a dedicated version of CC FW just for that purpose."  I need to hear clear design requirements.

I know of some people desperately waiting for the 3x version of the Picloc which is again delayed for several weeks.

I think the specs on rotorpics is what people are looking for. There are quite a few nice features listed. However implementing all of such features would keep you busy for a while I suppose.

[jes1111]

Those Picloc-2X specs look interesting, but I'm sure we can do better than that

One thing to bear in mind is that the Picloc will control a pan/tilt gimbal as well as a tilt/roll gimbal (presumably adding a layer of complication). I'm not at all sure we should try to get into pan/tilt gimbals at the moment - perhaps someone with more video experience than me can comment on that.

Something I do like a lot is the 560Hz, 760uS option - that would enable the use of very quick tail servos. Note also that the frame rate limit on most 1520uS servos is 333Hz. Also the "home position" command.

It strikes me that many of the servo configuration options listed overlap with the built-in capabilities of advanced digital servos. Would it be true to say that anyone interesting in a dedicated camera gimbal would naturally choose premium digital servos, and that therefore such setting from the controller are redundant?

The manual control from the Tx appears to offer (what we would call) rate and attitude modes. (What does he mean by "ATV"?)

EDIT: just to clarify - it's my belief that the responsiveness of the servos is as important, if not more so, than the actual rotational speed they can achieve - hence 560Hz/760uS digital servos are the obvious choice for optimum performance. If the servo hasn't even started moving by the time the next command update comes in... well, you're never going to win, are you?

Edited by jes1111, 05 July 2011 - 04:54 PM.

[Berkely]

jes1111, on 05 July 2011 - 04:42 PM, said:

(What does he mean by "ATV"?)

Adjustable Travel Volume for the servo's.

Another term...

[peabody124]

We already can support 760 us servos trivially.  Each channels pulse range is adjustable.

[nikivan]

jes1111, on 04 July 2011 - 11:11 AM, said:

Hi Nick,

Could you explain what you mean here by "360-degree gimbal"?

For a gimbal-dedicated CC - what functions would you like to see?

Jeremy

Hi Jeremy,

I build 360-degree aerial panoramas and for this I use camera gimbals that rotate full 360 degree around the Z axis. They currently don't have stabilized pitch and roll controls (X and Y axis) which is a problem in windy conditions when the entire platform tilts to fight the wind. Without pitch and roll stabilization large number of the images are either rotated or show a field above or bellow the desired direction. This makes it hard to stitch the panoramas, and in extreme cases I even end up with missing tiles.

Another case when you'd need 360 degree stabilized platform is for shooting video when you have second person operating the camera. You'd have an aerial platform that is completely independent from the camera gimbal. CC seems more than capable for handling camera stabilization. The requirements are really simple - accept pan tilt and roll commands from the camera operator (via second radio) and keep the camera in desired direction regardless of the attitude of the carrying platform. Your Z axis would operate at full 360-degrees. Tilt axis would operate at 180-degrees (camera pointing straight up and straight down) and roll axis would allow for 45-degree compensation in either CW or CCW direction. I hope this helps.

Cheers,
Nick

[aerialcameraman]

Hi
I am Denny Rowland and new around here. I have been creating these flying camera mount vehicles for a quite a while now, so I may be able to throw some light on how to get really super stable footage. I am not an EE but have plenty of experience in aerodynamics and carbon fiber technology.
I have started putting some videos together that provides some info on how to fix most of the problems that are connected with poor aerial footage.
The number one cause is of course vibration and my last video does show how I get around that problem
This video does however get into other types of camera mounts that I make but some of it you may find interesting. Once you are on Vimeo you can find some other relevant stuff. So my pro level camera system works like this, the FC provides the roll input as this is not that critical but pitch and yaw are controlled by a dedicated IMU that utilizes a 20 deg/sec gyro. IDG1150. I have a few imus that are cobled up from modified stock gyros boards, as you currently can't buy anything off the shelf that could do this job. (Opportunity here for someone!) What I aim for is a resolution of .1 us output from the imu and I then use the Hitec G2 and G2.5 servo boards and have 1 us deadband servos (Hitec). Obviously fast tailrotor servos are of no use as they don't have the resolution. The trick is to slow everything down, except the gyro response.

As I believe that the camera stabilisation starts with the model and then works backwards to the camera mount. My line of development is now centered around getting better aerodynamic response, stability and efficiency by totally rethinking the current trend in airfame design.
Consider this, If you want to make a move say to the left, then that starts with a bank to the left. But supposing you could utilize that signal to induce a sideways component into that force. The the copter would need very minimal bank!  
D.