Jump to content

Recommended Posts

A custom PCB is the only reasonable way to build this. So, for component choice, what would be best for those of you that are interested: SMT (smaller board, higher soldering skills) or through-hole parts (bigger board, but conventional assembly)?

I'm leaning towards SMT, so speak now or forever hold your peace!

Link to post
Share on other sites
  • Replies 344
  • Created
  • Last Reply

Top Posters In This Topic

Although I haven't been a part of this discussion, I've been following it for a little while now...

I'd have to say go SMT. It makes for a much smaller board, and reduces component height. The only thing I might consider is to have a DIP-to-SMT socket for any microcontrollers that would be used, that way, people with "hobby" programmers aren't left to find a way to program the devices. This also lends the ability to develop firmware while using the actual board.

Just my thoughts...

Edited by geogecko
Link to post
Share on other sites

Hi.

Like the other guy's I vote SMT.

In the last few days I was 'forced' to make a double sided through hole board 'its becoming tedious',what with aligning the tracks etc.

Also with SMT most of the time you get a choice of 'passive 'component phisical size.

Cheers Johnstorm.

Link to post
Share on other sites

SMT--I have all the gear.

One question:

The Copilot sensing system needs to be calibrated for weather variations that effect the differential sensitivity. Without this, an artificial horizon would not display an accurate angle. The Copilot achieves calibration by tilting the plane, nose down, to allow one sensor to see only sky, the other only ground. Is this what you envision or do you have a better plan? One means might involve observing the horizon through the video system before launch while holding the plane at a convenient bank angle. The sensitivity could be tweaked until the artificial horizon line matched the actual. The same gain factor could then be applied to both axiis.

One comment:

The Copilot has a limited bank angle ability because of the limited acceptance angle of the sensor windows. This issue is fully explained and resolved in this interesting research paper. If anyone has not yet seen it, it makes good reading. Of special interest is the very last line on the very last page referencing the FMA patent.

http://www.ctie.monash.edu.au/hargrave/hor...g_autopilot.pdf

Best,

T.I.

Link to post
Share on other sites

There will be a cal step, just like the Co-Pilot requires. I was going to use a 3-axis sensor that would have helped to eliminate this step. But, to keep the project "simple" I will use the stock 2-axis Co-Pilot sensor instead. If you already have the Co-Pilot then you can hijack the signals on the existing cable. That way you get the thermopile sensors for "free."

The FMA sensor module seems to provide more than enough off-axis range for the application. Actually, I was surprised how well it works. That positive news also contributed to my decision to use the stock module.

The intent of the project is to offer a simple brainless visual indication that you are flying level. Absolute values of pitch and roll {degrees} will not be offered. You will see little moving markers that will be just like the bubble in a carpenter's level. Hopefully that is all that you folks need.

Link to post
Share on other sites

I would strongly suggest to use 6-sensors (3-D) version of co-pilot. You can buy z-sensor separately from FMA for $45 if you have the original version. Yes, you can do calibration with 2-D version but it is time consuming and as soon as conditions change (and they can change throughout single flight) the calibration is void. I can definitely tell you that few thousands feet up 2-D version will not work if it was calibrated at take off point.

Regards,

Val.

Link to post
Share on other sites

The estimated development time and costs are already at the breaking point for me. To ensure the survival of the project I will focus on the essentials for now. The features that are needed for typical use are all that I will attack at this point. That means that the Z-axis sensor will not be used.

By the way, during calibration the Z-axis only seems to set the dynamic range for the ADC (max/min signal magnitudes). How does it help maintain calibration during flight? Isn't there still a need to perform the "level orientation" (model held perfectly level) cal step? As far as I can tell this was not eliminated in the new Co-Pilot. Do you have any links to technical info that shares the secrete to this?

Link to post
Share on other sites

I did notice that the new version of the co-pilot does not use the sensors for continuous autocalibration. If I recall correctly, the extra 2 sensors are intended for inverted roll recovery.

(Now for some speculation)

However, if you do have the two sensors and take them to be always "basically up and down", then you can sample and average them to determine the valid temperature differential for a given moment between sky and earth. If you are in a 90 degree bank forever, this could cause a problem. However, this problem could probably be mitigated with proper averaging and maybe with disabling autocal when autopilot gives strong banking commands. Actually, one can probably threshold the temp differential and use that as an autocal off command.

Link to post
Share on other sites
However, if you do have the two sensors and take them to be always "basically up and down", then you can sample and average them to determine the valid temperature differential for a given moment between sky and earth.

That is what I was going to do when I was mulling over the custom 3-axis thermopile concept. With some data windowing, this would set the dynamic range for the A/D. And like the Co-Pilot, it would determine if the conditions were good enough for use. But, the leveling cal step would still have been needed, just like the Co-Pilot. Or so I believe.

Instead of having to do it in the pits, I thought about allowing the pilot to perform a fly-by for this; flip a Tx switch as the VERY level model flew by and the level reference would be taken.

But for now I am Muntzing the design so that a mortal like me can design it in his meager free time. The custom video OSD is going to take an enormous amount of effort to create. Doing this will eliminate the need for the hard to buy Thompson OSD IC.

I have most of the descrete parts now. I am in the middle of moving the Engr Lab, so I will be down for a bit as things are put back in order.

Link to post
Share on other sites

Mr RC Cam, Val, T.I., Radio Flyer

My excuses, most therms you use sounds stranger to me but I found very interesting this thread.

Someone can explain me if the co-pilot really adjusts automatically its gain when doing the calibration so you will have the required servo reaction to stabilize the model either a day the co-pilot shows a 10 point temp. difference or a day with only 10 points temp difference? I ask you that because the last time I did the calibration procedure on my camera ship was 16 months ago(a day with a 10 p. temperature reading) and I fly the heli each weekend without noticing different behaviours.

May be you dont need to calibrate it. If it works right on my heli could work fine for your purposes too. Do it a day with a big IR diference reading, and for leveling stage cover the sensors with a ceramic receptacle to block the sensors reading and make them get the same reading for better leveling accuracy. Or make the calibration procedure daily but use always this leveling stage way to ensure you have always the same "0" on both axis for level flight

Elossam

Link to post
Share on other sites
By the way, during calibration the Z-axis only seems to set the dynamic range for the ADC (max/min signal magnitudes).

I don't own new co-pilot and I am not sure what they are doing. If they only measure IR amplitude at power up (even when they have z-sensor) it's too bad. It's a simple geometrical problem: if you have x,y,z readings the full apmplitude is

sqrt(x^2 + y^2 + z^2). There is no need for data windowing (may be a little averaging will be required), as long as processor can calculate square roots.

I also found that once co-pilot is calibrated it will work ok for days on that initial calibration. But that's because the goal of co-pilot is to stabilize a model at level attitude, which is not very sensitive to the exact IR amplitude.

Artifical horizon will require more precise knowledge of the exact amplitude. Z-sensor will help because it will make the system adaptive and increase accuracy at high attitude angles.

Those are just my thoughts - you may prove me wrong, but I vote for 3-d IR sensor.

Regards,

Val.

Edited by cyber-flyer
Link to post
Share on other sites

If the Z-Axis sensor is found to be needed then it will be added; some real in-flight experience needs to be gathered first.

If this was a commercial design then my design criteria would be very different. But, at this point it is just a personal navigation gadget that looks interesting to try out. So, it will probably not fullfill everyone's needs.

If anything, what is learned here may help the next guy design the holy grail of micro-sized artificial horizons. Frankly, I will be very pleased just to get a crude 2-axis prototype in the air.

Link to post
Share on other sites

Mr. RC-CAM,

I am most curious about your video overlay circuit to draw moving ticks. It sounds neat. Meanwhile I'll be playing with 3-D sensor because I already have it installed on my heli. Hopefully by the end of the summer we can make conclusion. More choices is better.

Val.

Link to post
Share on other sites

Cyber-Flyer, the OSD I have in mind is a simple genlocked design that is very primitive. It will basically be a sync detector and a microcontroller (probably a Zilog, but maybe a PIC). Because many of the CPU cycles are consumed in the generation of the overlay video, little time will be available to other chores. There is a chance it will not work well in this app, at which point I will shift over to the STV5730 IC.

I am interested in what you find out with your 3-Axis sensor. I still do not fully understand how it will offer full auto-cal. I recognize how it can determine the dynamic range (that takes care of the Nose-Down cal step) and the changes to this as the environment changes. But the leveling Cal step part is where I am stumped. And at high altitudes (several thousand feet) I expect the thermopiles' ratiometric issues to come into play (earth's horizon shifts down, with or without a change is dynamic range). The only way I can see to compensate for that is to re-zero the "level" attitude (either mentally or electronically). However, I am hoping that the error is too small to worry about.

If you have used the Co-Pilot at above 5K feet AGL, did you find it to maintain a level flight? That would help me a lot to know how it behaved at heights well above what most folks will fly in.

Link to post
Share on other sites

It seems to me that once the differential gain error is accounted for with calibration, altitude errors will be only common mode.

BTW, how many posts until I move up to "gaffer?" These backdrops are getting freaking heavy.

T.I.

Edited by Temporary Insanity
Link to post
Share on other sites

Mr. RC-CAM,

True auto leveling capability is hard to build. I was talking about using z-sensor for accurate IR amplitude read. For example, if roll angle is arcsin((x-xo)/ampl), where xo is differential signal coming from x sensor corresponding to 0 degree of roll, ampl - is full amplitude of IR gradient as read from 3 diff sensors = sqrt((x-xo)^2 + (y-yo)^2 + (z-zo)^2). xo needs to be set once by calibration of sensor head. But the amplitude will change depending on time of day and altitude of flight. The presense of z-sensor will "auto" calibrate the amplitude. The biggest change will be near cloud cover (as much as factor of three by my estimate). This means that you may think the roll is 10 degrees (using ground IR amplitude) while it is actually 30 degrees. Does it make sense?

Regards,

Val.

Link to post
Share on other sites

I fully understand. Let's see if I get far enough to have something to put in the air. Then I can experience first hand how the issues affect a typical flight. Keep in mind that I will not attempt to accurately measure the absolute pitch or roll angle (but I do need to be able to establish when pitch and roll are level).

I have a feeling that your (and perhaps many other folks') performance requirements are much more stringent than what I have time to develop. I would be thrilled to have a simple artificial horizon displayed on my video, that worked for at least thirty minutes at a time, several hundred feet up, on a pleasant flying afternoon.

Link to post
Share on other sites

I have prototyped the basic video overlay circuit. So far, it consists of two IC's (a PIC and a low cost sync detector). Total component count is minimal -- about eight caps and resistors are in there too. Nothing special. So far. The IR sensors are not yet incorporated into it.

Even with the PIC running at 20Mhz (5MIPS) there is jitter in the overlayed pixels. But rather than upgrade to a fast Zilog processor I think I will just leave it as-is.

I created a video clip that demonstrates the vertical (pitch) glyph and its level indicator tick mark. The Roll indicator is turned off. You can clearly see the jitter in the overlayed pixels. Poor Man's OSD Demo

The engr lab is still half moved, so I need to abandon this project for awhile so that I get things back in order. And flying weather is starting to get real nice, so that is another distraction from the endless soldering and programming. ;)

Link to post
Share on other sites

How about one of the PICs that run at 40Mhz now. I haven't tried them yet but might be worth looking at.

As for flying weather being a distraction, I hear that. Been out flying about 6 times in the past 3 weeks.

Got to love these days (well maybe not all the mud).

Mike

Link to post
Share on other sites

I've been looking at those new PIC's too. But, they would only get me 10MIPS. Unless I add more hardware to the design, or can get my other firmware idea to work, I will need a much faster MCU to tame the pixel jitter (its at ~0.5uS now, which is 10X too much). The soon to be released dspPIC's would probably work great (but then cost and development tools get in my way).

So, given my personal design goals (must be cheap, small, and easy-to-duplicate by mortals), I will probably just live with what I see. An improved version may come about if there is any success at all to this version.

Link to post
Share on other sites

Now that is impressive, irrespective of the pixel jitter.

Was it a hard project to design? Are you actually processing the whole video stream through the PIC?

Very neat stuff. I'd be curious to hear (at a high level) what your approach was.

Bill

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...