Author Topic: Data logging accelerometer (Read 3262 times)

Brett Buck · « **on:** December 14, 2021, 09:28:20 PM »

Has anyone tried logging the fore/aft (X axis) of their 3-axis accelerometer? I think Igor only uses one axis of it, Y. I am curious what the acceleration looks like into and out of a corner.

Brett

Howard Rush · « **Reply #1 on:** December 15, 2021, 12:28:26 AM »

Quote from: Brett Buck on December 14, 2021, 09:28:20 PM

Has anyone tried logging the fore/aft (X axis) of their 3-axis accelerometer? I think Igor only uses one axis of it, Y. I am curious what the acceleration looks like into and out of a corner.

Brett

Here's a sample. Accelerations are not corrected to CG, because I haven't been that interested in them.

I think Igor uses X and Y accelerations.

Rogerio Fiorotti · « **Reply #2 on:** December 15, 2021, 03:30:17 AM »

Forces acting on the y and x axes.

X axis mounted inverted due to negative values.

Rogerio

Howard Rush · « **Reply #3 on:** December 15, 2021, 01:02:30 PM »

Quote from: Rogerio Fiorotti on December 15, 2021, 03:30:17 AM

Forces acting on the y and x axes.

X axis mounted inverted due to negative values.

Rogerio

Looks like your axis definitions are different than ours. It also looks like you need tip weight.

Mark wood · « **Reply #4 on:** December 15, 2021, 02:19:39 PM »

Quote from: Howard Rush on December 15, 2021, 01:02:30 PM

Looks like your axis definitions are different than ours. It also looks like you need tip weight.

How do draw that conclusion, Howard?

Tim Wescott · « **Reply #5 on:** December 15, 2021, 05:04:00 PM »

Yes, but it doesn't look right to me -- I'd expect a 2g peak-peak variation in the x axis in the loops.

CircuitFlyer · « **Reply #6 on:** December 15, 2021, 06:19:44 PM »

I was also surprised. I thought I'd see more fluctuation in the x-axis. Recorded on an Adafruit Feather Sense with some filtering applied

Howard Rush · « **Reply #7 on:** December 15, 2021, 06:26:22 PM »

Quote from: Mark wood on December 15, 2021, 02:19:39 PM

How do draw that conclusion, Howard?

Axes are clearly different than standard US convention, which Tim, Brett (for x, anyhow), and I use. Then there's the label "G Force", which I presume is acceleration in Gs. My guess is that Eagle Tree labeled their acceleration data according to what RC fliers wanted the name to be. (The Eagle Tree folks lived about 100 meters from my old house, next to the same green belt, where eagles, bears, and other critters lived but that's another story.) Rogerio's pink trace is something close to y acceleration. If the pink trace were x acceleration, the airplane would be going backward at 20,000 MPH at the end of the flight. After takeoff, the pink trace is about -3.2G, which level flight y acceleration would be for a 5-second lap on 66-ft. lines. The darker trace looks like x acceleration, but maybe with the accelerometer tilted forward about 10 degrees. Signs are conventional: x acceleration is positive during takeoff, and y acceleration has a negative bias for the whole flight.

I was probably wrong about tip weight. His maneuvers aren't much different from Tim's and mine. Rogerio's Y acceleration got close to zero at the last part of the square eight, but had a positive increment on some bottoms. I know where he can get an active timer to ameliorate that effect.

Mark wood · « **Reply #8 on:** December 15, 2021, 07:05:29 PM »

Quote from: Howard Rush on December 15, 2021, 06:26:22 PM

I was probably wrong about tip weight. His maneuvers aren't much different from Tim's and mine. Rogerio's Y acceleration got close to zero at the last part of the square eight, but had a positive increment on some bottoms. I know where he can get an active timer to ameliorate that effect.

Thanks Howard. I wasn't seeing where I could pick off rolling acceleration. I'm going to guess the nose turned in some during the last section.

I don't think I'd expect 2g P-P Tim. I'd expect something like g-(Thrust -Drag)/M P-P without active thrust modulation. But I've been wrong before.

pmackenzie · « **Reply #9 on:** December 15, 2021, 10:01:14 PM »

Main source of measured fore/aft acceleration value will be lift*sin(AoA).

Howard Rush · « **Reply #10 on:** December 16, 2021, 12:38:35 AM »

Quote from: pmackenzie on December 15, 2021, 10:01:14 PM

Main source of measured fore/aft acceleration value will be lift*sin(AoA).

That's a good point. So increasing the elevator/flap ratio will effectively increase throttle gain. Reducing air density will effectively increase throttle gain. Elevator bias could feel like a wing warp. Y axis sensor tilt could feel like x axis sensor tilt. It's a reminder that we should trim the airplane with the throttle sensitivity zero.

Tim Wescott · « **Reply #11 on:** December 16, 2021, 05:01:08 PM »

On the lack of fore-aft acceleration -- if the loops were happening at a constant speed, then you'd expect -1g going up, and +1g going down due to the warping of space-time itself (or the pull of gravity, if you want to be all traditional about it). From which I -- belatedly -- deduce that not much speed regulation is happening, at least not in such a short period of time. That would mean that the plane is significantly slowing down on the upward legs and speeding up on the downward legs.

Howard's plot shows a lot more variation than mine (feet per sec², really?). I assume that's because he's using a Burger timer, and that it's regulating speed more.

AMV · « **Reply #12 on:** December 16, 2021, 07:03:34 PM »

Quote from: Tim Wescott on December 16, 2021, 05:01:08 PM

On the lack of fore-aft acceleration -- if the loops were happening at a constant speed, then you'd expect -1g going up, and +1g going down...

More like at most +/-0.92g (cos 22.5°) when 1/4 or 3/4 through the loop. Also, gravity's contribution is 0.0g at the top/bottom of the loop because at those two points the aircraft's fore/aft axis is perpendicular to the gravity vector; so any acceleration then is due to any actual change in speed. It is somewhat continuous between those limits throughout the whole loop. Gravity's contribution is attenuated even further in the loops above the 45 latitude; i.e., in tops of vertical 8's and the overhead.

-Andrey

Mark wood · « **Reply #13 on:** December 17, 2021, 07:52:31 AM »

Sorry but this is a task on my to do list for some time and I had to work it out.

Accelerometer indication in x axis

A – Gross acceleration of vehicle – sign dependent on accelerometer installation
Theta – clock angle of the flight path
Phi – Spherical angle from horizon to vehicle
T – Thrust
D – Total drag
g – Acceleration due to gravity
G – G vertical force in terms of g

Well, we've entered a transform into the acceleration domain which is intuitively strange. I agree the acceleration should look something like A=g*sin(theta) at constant velocity and at theta = 90 and 270 the acceleration should be g and –g in non-spherical geometry and considering the accelerometer remaining tangent to the flight path.

However, with constant thrust the nose up acceleration would be g + the net excess or deficit thrust divided by mass which is actually probably slightly negative due to drag, A=g*sin(theta)+(T-D)/M. Constant RPM does not equal constant thrust. Constant power with a variable pitch propeller would be close. For simplicity of evaluation I’m using constant thrust. We would expect the airplane to decelerate with elevator pitch command. It’s apparent in Howard’s data and the timer does a good job of responding to G load but has some lag probably from filtering and or deadband. The lag could be fixed with some anticipation gain from the elevator.

In the case of the PA airplane in a high G maneuver the drag is significant and the airplane leaving constant level flight where the thrust equals the drag (T = D) would then have T<D and it would be expected to be decelerating independent of the g field. So for this airplane we would expect the acceleration to be A=g+(T-D)/M when the nose is pointed vertically if there were no change in thrust and then A<g and if the thrust were in excess of the drag A>g. The latter is not likely unless the thrust controller were over shooting.

An airplane crossing through the horizon will experience a reduced G requirement in order to draw a proper circle. In this case the required lift and drag would be reduced and the airplane would accelerate at (T-D)/M. g*sin(180) = 0. So the accelerometer would continue to indicate some non-zero value.

As the airplane traverses into the third quarter with the nose down, intuitively we would expect the accelerometer to indicate -g and would if the airplane were flying at constant velocity. With constant thrust the airplane is again going to accelerate. The condition of zero acceleration would be when the weight equals the thrust minus drag, same as before. So, with the nose down A<g but in this case the g vector is reversed and the airplane would have to have a fairly significant excess thrust to get the acceleration to turns signs. I the 4/4 world, I slam the throttle on as soon as the nose points downward in order to accelerate to my next maneuver speed as quickly as possible. This conserves the altitude potential energy which we haven’t looked at this from that perspective which is actually a better way.

Mr Mackenzie pointed out that there is a coupling in the accelerometer which is equal to the pitch angle of the accelerometer with respect to the flightpath, tangent of the circle, probably AOA or close enough to consider it so. So we'd expect a significant impact of this at times such as in the squares and the OH8's. Watch the AOA video, the peak AOA's occur in the OH8's. This means the acceleration A= g*sin(theta)-(T-D)/M+G*sin(alpha).

But wait there’s more… Well, one more simple addition to account for the operation on a sphere. The g vector is not always perpendicular so the g term is actually g*sin(phi) which results in A= g*sin(theta)*sin(phi)-(T-D)/M+G*sin(alpha).

Then again I could be wrong, it’s happened before.

Howard Rush · « **Reply #14 on:** December 18, 2021, 01:30:23 AM »

It might be handy to be able to read the active-timer accelerometer signals so one could look at them to level the sensor package with the airplane leveled in pitch and roll on the ground.

pmackenzie · « **Reply #15 on:** December 18, 2021, 06:43:57 AM »

Quote from: Howard Rush on December 18, 2021, 01:30:23 AM

It might be handy to be able to read the active-timer accelerometer signals so one could look at them to level the sensor package with the airplane leveled in pitch and roll on the ground.

I assume that is what the calibrate flight is for.

Mark wood · « **Reply #16 on:** December 18, 2021, 07:18:30 AM »

Quote from: Howard Rush on December 18, 2021, 01:30:23 AM

It might be handy to be able to read the active-timer accelerometer signals so one could look at them to level the sensor package with the airplane leveled in pitch and roll on the ground.

I think Tim's TUT can do this.

Howard Rush · « **Reply #17 on:** December 18, 2021, 10:04:10 AM »

Quote from: Mark wood on December 18, 2021, 07:18:30 AM

I think Tim's TUT can do this.

Not the cheap version I got.

Howard Rush · « **Reply #18 on:** December 18, 2021, 10:11:51 AM »

Quote from: pmackenzie on December 18, 2021, 06:43:57 AM

I assume that is what the calibrate flight is for.

My understanding is that the calibrate flight just learns what sideways acceleration to expect so changes in sensitivity don’t cause lap time changes. Igor?

Tim Wescott · « **Reply #19 on:** December 19, 2021, 04:47:05 PM »

Quote from: Mark wood on December 18, 2021, 07:18:30 AM

I think Tim's TUT can do this.

Well...

Quote from: Howard Rush on December 18, 2021, 10:04:10 AM

Not the cheap version I got.

Yes, that -- but Howard did ask for small, and so some functionality was thrown out to conserve board space.

I don't have a version that can record stuff nicely enough to inflict on even the top 10% of the class of computer-literate CL pilots, and the one that I do have that can record data is old and bigger than Howard's version. The data that I recorded above was done with that previous version -- it only had enough storage space to record one flight. After each flight you had to hook up to it and suck the data off using techniques and know-how that are perfectly normal for anyone who routinely does professional embedded systems development. But it's not something that you'd want to ask regular folks to do.

I have a version that has a Micro SD card on it (like you find in cameras), but again, it's bigger, and I need to get the lowest layer of software to play nice with the SD card, and (A) that hasn't happened yet, and (B) I've kinda stalled out. Howard lost patience with me and came up with his own data recording solution -- good for him.

I think (contrary to Brett Buck's judgement -- we're currently at duelling intuitions, with no one having generated a data set to test things on) that with the current crop of cheap cell-phone IMUs I can get good enough data to reconstruct a flight just from IMU data -- or at least get enough data to know how fast the airplane is going with respect to the ground. With that and a fast enough response on the thrust, one could hold the aircraft at a constant airspeed.

Looking at the lengthwise acceleration plots, though, I think you'd find that the thing would really behave counter-intuitively. I know that Paul Walker has dialed back the gain on his Burger timer because he didn't like how much the plane slowed down on the down legs of the square maneuvers. I think it would be interesting to hand the pilot an active timer that could be tuned in pilot's terms, starting with some sliding scale going from 0% inertial control (i.e., rock solid motor speed) to 100% inertial control (i.e., rock solid speed with respect to ground, never mind altitude, attitude, or wind speed).

Mark wood · « **Reply #20 on:** December 19, 2021, 06:01:23 PM »

Quote from: Tim Wescott on December 19, 2021, 04:47:05 PM

Well...

Yes, that -- but Howard did ask for small, and so some functionality was thrown out to conserve board space.

I don't have a version that can record stuff nicely enough to inflict on even the top 10% of the class of computer-literate CL pilots, and the one that I do have that can record data is old and bigger than Howard's version. The data that I recorded above was done with that previous version -- it only had enough storage space to record one flight. After each flight you had to hook up to it and suck the data off using techniques and know-how that are perfectly normal for anyone who routinely does professional embedded systems development. But it's not something that you'd want to ask regular folks to do.

I have a version that has a Micro SD card on it (like you find in cameras), but again, it's bigger, and I need to get the lowest layer of software to play nice with the SD card, and (A) that hasn't happened yet, and (B) I've kinda stalled out. Howard lost patience with me and came up with his own data recording solution -- good for him.

I think (contrary to Brett Buck's judgement -- we're currently at duelling intuitions, with no one having generated a data set to test things on) that with the current crop of cheap cell-phone IMUs I can get good enough data to reconstruct a flight just from IMU data -- or at least get enough data to know how fast the airplane is going with respect to the ground. With that and a fast enough response on the thrust, one could hold the aircraft at a constant airspeed.

Looking at the lengthwise acceleration plots, though, I think you'd find that the thing would really behave counter-intuitively. I know that Paul Walker has dialed back the gain on his Burger timer because he didn't like how much the plane slowed down on the down legs of the square maneuvers. I think it would be interesting to hand the pilot an active timer that could be tuned in pilot's terms, starting with some sliding scale going from 0% inertial control (i.e., rock solid motor speed) to 100% inertial control (i.e., rock solid speed with respect to ground, never mind altitude, attitude, or wind speed).

Nice..

Well, I understand what the debate is on the IMU, mostly, I think. I don't know if I have an opinion on that. What I see in Howards data plot is a lag in response of the power system. It takes a fairly "long time" for the deceleration to stop and turn around, data wise. It eyeballs to be 100 ms. This lag, in turn, can be perceived by the meat servo and will generally result in over compensation to the "improve" the response time or to reduce the velocity droop. It won't, gain isn't driving the lag. It's the droop that's driving the lag. I can't tell exactly but it looks like this a dead band thing as the response appears to have a distinct trigger ( ~ 150 - 200 ft/s^2) as opposed to a filter which would have a less distinct turn around. The result of pushing the gain to get the response back is pumping of the velocity as they lag causes an out of phase condition in the velocity/thrust response. In the first corner of the triangle the thrust didn't peak until being most of the way through the corner. This repeats every time.

I don't think this is a problem with the way the acceleration or attitude is being detected unless the timers accelerometer is vastly different the data source accelerometer and I can't conceive of any reason that would be. The x acceleration shows a constant decay from the onset of pitch rate and Z accel until it reaches a point an makes a very sharp turn. This is indicative of a gain loop with a dead band which is used to prevent unwanted oscillation around the set point. Once the dead band is reached, the gain takes off following quite well. A pot of the motor command output would show a sharp step up to the threshold gain and then increase from there. The turn around shows a reduction in the response lag which seems about right. The x acceleration is consistent with the gain rolling back as the nose finds the line and the G is reduced.

It wouldn't take using a load cell on the bellcrank as sensor to fix this and I think Tim has considered using an input from the elevator control. This would provide some anticipation of the load coming on and help fix the lag and consequently the droop. Provided it is implemented correctly. How we handle this in helicopter engine controls is pretty much like that. We pick off a signal from the control system, in the case of the RAH66 all four controls had RVDTs on them, pitch, roll, yaw and collective. This is done because if you wait too long to respond, the rotor system RPM will droop and not be quickly recoverable resulting in lost maneuverability. This anticipation gain is put inside the governing loop for the gas generator in a form similar to an integral gain with the exception that it is spiked up as function of control rate then it decays quickly allowing the other terms to take over. The helicopter engine has two turbines, the gas generator that creates the energy to run the power turbine which runs the rotor system gearbox. They are separate and only connected by the gas stream., We pump the GGT because it takes time to get the energy ball rolling. The power turbine has a droop control as well but is basically enters in to a least-most gain wins set of computations in the GGT control loop.

Howard Rush · « **Reply #21 on:** December 19, 2021, 07:58:52 PM »

Quote from: Mark wood on December 19, 2021, 06:01:23 PM

I don't think this is a problem with the way the acceleration or attitude is being detected unless the timers accelerometer is vastly different the data source accelerometer and I can't conceive of any reason that would be.

They are in vastly different locations.

Tim Wescott · « **Reply #22 on:** December 19, 2021, 08:57:32 PM »

Quote from: Mark wood on December 19, 2021, 06:01:23 PM

It wouldn't take using a load cell on the bellcrank as sensor to fix this ...

I'm not sure if you literally mean a load cell. The best option I know about is to use a Hall effect absolute position sensor -- it's contactless, easy to source (or at least was, pre-COVID), fast, little -- it's almost everything you want. It does require a specific arrangement of bearings and bellcrank mount, so it's not a simple retrofit.

So far I've sorted through my RC-stuff collection for the freest-moving servos, gutted them, and fitted them with pulse generators (search on "Aunti-servo" for pictures). They seem to work, but I hunted down the Hall effect thingie for Howard because the least friction is no friction at all.

Howard Rush · « **Reply #23 on:** December 19, 2021, 09:08:06 PM »

I have a Hall-effect position sensor on the new dog for control position. Another Pat MacKenzie recommendation.

Mark wood · « **Reply #24 on:** December 20, 2021, 12:46:20 AM »

Quote from: Tim Wescott on December 19, 2021, 08:57:32 PM

I'm not sure if you literally mean a load cell. The best option I know about is to use a Hall effect absolute position sensor -- it's contactless, easy to source (or at least was, pre-COVID), fast, little -- it's almost everything you want. It does require a specific arrangement of bearings and bellcrank mount, so it's not a simple retrofit.

So far I've sorted through my RC-stuff collection for the freest-moving servos, gutted them, and fitted them with pulse generators (search on "Aunti-servo" for pictures). They seem to work, but I hunted down the Hall effect thingie for Howard because the least friction is no friction at all.

Yes, I meant literally instrumenting the bellcrank, not my idea. The other discussion. I'm not clear what the original reasoning for it was but with this one, I thought maybe as part of an input. Not a good way to do it. The Hall effect would be what I would do. I'd make a mount myself but gutting a servo would be good too.

Provide a link. I'll put it on my list of things to create.

Mark wood · « **Reply #25 on:** December 20, 2021, 08:25:38 AM »

Quote from: Howard Rush on December 19, 2021, 07:58:52 PM

They are in vastly different locations.

It would take seeing the data to really understand the difference but I wouldn't expect the two locations to make that much of a change in the net evaluation of the power system response. The x axis surely wouldn't be much different and the Z axis magnitude might be different due to the distance between the locations but the phase lag between them would still be evident. The conclusion would remain the same, there's a lag in the control which results in droop in Vx as seen in the plot of Ax. Using G-g as a gain isn't going to prevent the droop since Ax is a function of G via D = f(Cd(AOA)). Even the generation of the error points to using using control angle for the gain computation via D=f(Cd(f(control angle))).

If I was going to create a new power control, not saying I have worked on one for models, I would not use G force as my primary error generator and more than likely not at all. That's the source of the lag seen here. I'd use attitude, control system rate and position realizing that acceleration is being used to get attitude. Turning harder means more drag requiring more power, G is the result, control input is the driver to that G. Since there is also a lag in the powerplant response the lag is increased. That really isn't desirable in the powerplant control for maneuvering response. The control will eventually close the error given a step input but if there is a cyclic input the lag may causes divergence. We call that wind up in loops.

We knew this before we ever made our first FADEC as we used a control input to the hydromechanical governors being used. That input did two things. It reset the speeder spring which changes the power demand and also commands an acceleration of the gas generator control in anticipation of the upcoming load and potential droop. Using only a speed governor with no load anticipation and speed reset would result in droop overshoot and consequent oscillation. If the load is too high the resulting droop becomes large enough that the engine cannot recover the droop without melting down. This is essentially what the current active timers do. They aren't closed loop per se but they act as a gain in the full system, meat servo, lines, airplane. In order to reduce the droop and lag an input from the control is required.

Tim Wescott · « **Reply #26 on:** December 20, 2021, 09:39:38 AM »

Quote from: Mark wood on December 20, 2021, 08:25:38 AM

... I'd use attitude, control system rate and position ...

Getting accurate attitude and position is hard -- at least if, by "position", you mean the height above the baseline of the hemisphere. It's actually the ultimate goal of the TUT, and the thing that Brett Buck and I disagree on whether it can be had from cellphone-quality IMUs.

Tim Wescott · « **Reply #27 on:** December 20, 2021, 10:45:04 AM »

Quote from: Mark wood on December 20, 2021, 12:46:20 AM

Provide a link. I'll put it on my list of things to create.

Lean on Howard for how he did his -- I made suggestions, but I'm not sure what he actually ended up with.

Here's a video of a Legacy wing with a servo-turned-sensor on it. For some reason it sounds like there's a servo turning when I move the controls -- it's some control arm rubbing on something, really, honest!

Mark wood · « **Reply #28 on:** December 20, 2021, 11:49:24 AM »

Quote from: Tim Wescott on December 20, 2021, 09:39:38 AM

Getting accurate attitude and position is hard -- at least if, by "position", you mean the height above the baseline of the hemisphere. It's actually the ultimate goal of the TUT, and the thing that Brett Buck and I disagree on whether it can be had from cellphone-quality IMUs.

No, I don't mean aircraft position. I actually don't think a high resolution knowledge of that is necessary. I meant position of the flight control. Back up a step and look at the system as a whole in terms of total energy. The height variation isn't much and you can do everything needed by knowing the direction of the gravity vector. The only reason we need to know that is whether to add or subtract g from any gain we derive. Let me use the helicopter engine control because it does pretty much exactly what is necessary for the CLPA airplane. We take off the control position from the collective via an RVDT. From that we can get the two things we need to know. How much power is required and how fast the requirement is changing.

So the helicopter at flat pitch has a base amount of power required. It's called the parasite power. That will never change. As we increase the collective pitch which increases thrust via angle of attack and drag increasing the power demand. We have a first order gain in the control system which feeds the set point of the Gas Generator Turbine, GGT. Say we 're going from 100 hp to 120 hp then the output of the gas generator has to increase it's output to 120 hp to the power turbine, PT, which drives the rotor system. The power turbine has a speed governor in it as well which feeds the GGT governor. We could forgo the anticipation used in the GGT and allow the rotor speed to droop and the PT governor see an error grow and feed this error to the GGT. Because of the lags in this loop the result will be some droop and oscillation in rotor speed. We know by analysis and testing that the rotor will require power as a function of collective pitch angle. We also know what the GGT speed With Respect To power is. So we can use those to predict the power target and change Ngg as a function of control position. Cool right. In the event of signal loss we can also accommodate that via calculation with minimal performance loss. By doing this we reduce the droop and overshoot significantly because we're not relying upon the droop created error signal. The later is how the CLPA timer control works, it generates gain based on the resulting droop as created by G.

That anticipation built in to the GGT governor isn't perfect and along side of the GGT we're doing a parallel droop error within the PT governor and comparing the gains through a least wins gate. When the power of the GGT is sufficient the PT governor takes over via this gain gate. We also take the control input an integrate the rate it's changing and add that to the position signal. This then gets compared in a most wins gate. This rate input helps get the GG rolling in anticipation oncoming load and since it is an integral type gain it washes out with a decay rate we can trim.

To apply this to a CLPA airplane is simple. We know the drag is going to increase whenever we maneuver and that drag is a function of the AOA which in turn is a function of the control position. Similar to the helicopter rotor control system we can use the control position input to change the thrust. Go back and watch the AOA video I made. The flap has position indicator on it. There's more than one reason I did that. The highest AOA occur in the OH8's. This means that the largest control deflections also occur in the OH8's. Using control position to adjust the power setpoint would do almost everything necessary for the CLPA. I'd guess that there is really no need to use the y axis acceleration but we do want to know whether the nose is pitching is up or if it is pitching down. In that case we would adjust the gain by a function of the previously derived x axis attitude calculation. Or some variation thereof.

Tim Wescott · « **Reply #29 on:** December 20, 2021, 10:34:02 PM »

Quote from: Mark wood on December 20, 2021, 11:49:24 AM

No, I don't mean aircraft position. I actually don't think a high resolution knowledge of that is necessary. I meant position of the flight control. Back up a step and look at the system as a whole in terms of total energy.

Well....

Two things: first, I think that in order to get a really accurate aircraft attitude and velocity you need to track the aircraft state well enough that you'll know it's position pretty well, too. So when I didn't mean "get an accurate position and get an accurate attitude". I meant that position and attitude come as a package, and leaving out velocity as part of the package was an oversight.

Second, back up a bit more and look at the whole system as being driven (and paid for) by a brain that's spent the last 50 years flying planes that slow down going up, speed up going down, and generally fly slower when they're up high. I'm not sure that if you did achieve a perfectly regulated speed in inertial space that the pilots or spectators would enjoy it. You may find yourself flying a plane in Uncanny Valley, in fact. And the guy thinking "damn, my plane flies weird with this timer" is the guy who writes the checks.

I know that Igor Burger mentioned to me at one point that he felt that the speed regulation could be too good, and, there's always the comment by Paul Walker that he turns the speed regulation gain down because he doesn't like the constant speed.

Personally, I think that if you could get a plane that has rock solid speed control (in inertial space) and then you spent a couple of years practicing with it, that you may get a combination that flies very well indeed. But I'm not sure you could get a 50- or 60 year old Nationals or World Champion prospect to take two or three years re-training their reflexes, and I'm not sure if you did actually get a perfect pattern at a constant speed if the judges would like it.

I also think that if you're serious about helping out the community with a speed control, you can't just offer a rock-solid inertial speed. Having gently bounced ideas off of a few people who fly active timers, I'm pretty sure that for a lot of people the best compromise is somewhere in between a constant motor speed (i.e., Hubin + goverened ESC) and an absolutely perfectly regulated speed in inertial space. This is why I mentioned earlier in this thread that a timer that offers just that -- perhaps even as a settable percent -- is something to seriously consider.

Ken Culbertson · « **Reply #30 on:** December 21, 2021, 11:49:33 AM »

Quote from: Tim Wescott on December 20, 2021, 10:45:04 AM

Lean on Howard for how he did his -- I made suggestions, but I'm not sure what he actually ended up with.

Here's a video of a Legacy wing with a servo-turned-sensor on it. For some reason it sounds like there's a servo turning when I move the controls -- it's some control arm rubbing on something, really, honest!

This is beyond cool. It would have wild bill rolling over in his grave. Fly by wire. If done without the aid of radio it is probably legal. It might even be legal to eliminate the bellcrank entirely and have the signal come directly from the handle as long as it was done w/o the aid of radio. So after designing the ultimate arm mounted Joy Stick we reference further and find there is only a 1 line requirement and although there is a requirement to have the center of the circle marked, I can find no requirement to have the pilot stand in it!. So we *could* have a 5' center post that we borrowed from the speed guys tether the plane while we sit back and fly from our lawn chairs. And that is just the beginning... How long before we become just a VR app?

I would support a rule change to block this sort of thing from ever happening, but it won't. It is building season and the mind wanders.

Ken

Tim Wescott · « **Reply #31 on:** December 21, 2021, 01:53:31 PM »

Quote from: Ken Culbertson on December 21, 2021, 11:49:33 AM

This is beyond cool. It would have wild bill rolling over in his grave. Fly by wire. If done without the aid of radio it is probably legal. It might even be legal to eliminate the bellcrank entirely and have the signal come directly from the handle as long as it was done w/o the aid of radio. So after designing the ultimate arm mounted Joy Stick we reference further and find there is only a 1 line requirement and although there is a requirement to have the center of the circle marked, I can find no requirement to have the pilot stand in it!. So we *could* have a 5' center post that we borrowed from the speed guys tether the plane while we sit back and fly from our lawn chairs. And that is just the beginning... How long before we become just a VR app?

It is not a servo -- it used to be a servo. It's a servo that's been gutted of all its gears, and the electronics replaced with a sensor transmitter. It's just a convenient position sensor mounted to a shaft, in a box with room for electronics, all packaged in a way that matches the vernacular of connecting stuff up mechanically inside a toy airplane.

Quote from: Ken Culbertson on December 21, 2021, 11:49:33 AM

I would support a rule change to block this sort of thing from ever happening, but it won't. It is building season and the mind wanders.

Ken

Too late -- that rule got accepted this rules change cycle. Brett Buck started it but ended up just throwing it to the community. I completed it and filed it.

No moving flight controls by any means other than mechanically.

No thrust vectoring by any means other than mechanically (edited: I left out the "other than mechanically" earlier, and caused confusion thereby. When it doubt, read the rules).

Thrust control via motor speed or pitch changes is allowed, but only if it does not change direction of thrust.

Ken Culbertson · « **Reply #32 on:** December 21, 2021, 03:27:11 PM »

Quote from: Tim Wescott on December 21, 2021, 01:53:31 PM

It is not a servo -- it used to be a servo. It's a servo that's been gutted of all its gears, and the electronics replaced with a sensor transmitter. It's just a convenient position sensor mounted to a shaft, in a box with room for electronics, all packaged in a way that matches the vernacular of connecting stuff up mechanically inside a toy airplane.

Too late -- that rule got accepted this rules change cycle. Brett Buck started it but ended up just throwing it to the community. I completed it and filed it.

No moving flight controls by any means other than mechanically.

No thrust vectoring.

Thrust control via motor speed or pitch changes is allowed, but only if it does not change direction of thrust.

I should have read all of them! Good Job guys. Protecting us from ourselves is a noble endeavor!

Ken

Mark wood · « **Reply #33 on:** December 21, 2021, 05:19:26 PM »

Quote from: Tim Wescott on December 20, 2021, 10:34:02 PM

Well....

Two things: first, I think that in order to get a really accurate aircraft attitude and velocity you need to track the aircraft state well enough that you'll know it's position pretty well, too. So when I didn't mean "get an accurate position and get an accurate attitude". I meant that position and attitude come as a package, and leaving out velocity as part of the package was an oversight.

Second, back up a bit more and look at the whole system as being driven (and paid for) by a brain that's spent the last 50 years flying planes that slow down going up, speed up going down, and generally fly slower when they're up high. I'm not sure that if you did achieve a perfectly regulated speed in inertial space that the pilots or spectators would enjoy it. You may find yourself flying a plane in Uncanny Valley, in fact. And the guy thinking "damn, my plane flies weird with this timer" is the guy who writes the checks.

I know that Igor Burger mentioned to me at one point that he felt that the speed regulation could be too good, and, there's always the comment by Paul Walker that he turns the speed regulation gain down because he doesn't like the constant speed.

Personally, I think that if you could get a plane that has rock solid speed control (in inertial space) and then you spent a couple of years practicing with it, that you may get a combination that flies very well indeed. But I'm not sure you could get a 50- or 60 year old Nationals or World Champion prospect to take two or three years re-training their reflexes, and I'm not sure if you did actually get a perfect pattern at a constant speed if the judges would like it.

I also think that if you're serious about helping out the community with a speed control, you can't just offer a rock-solid inertial speed. Having gently bounced ideas off of a few people who fly active timers, I'm pretty sure that for a lot of people the best compromise is somewhere in between a constant motor speed (i.e., Hubin + goverened ESC) and an absolutely perfectly regulated speed in inertial space. This is why I mentioned earlier in this thread that a timer that offers just that -- perhaps even as a settable percent -- is something to seriously consider.

Well, yes, I agree. Especially in the perfectly regulated speed aspect. I have flown the Hubin combination allot and it works very well. The only thing I use in the Fiorotti is the attitude and not a huge amount. The G force is out of phase and I don't use it. My honest opinion is that using a control system input in combination with the ESC governor with enough flexibility in the trim of the gains would likely be plenty adequate. That's something simple enough that even I could cobble together. Some people could do a better job of it than me of course as it isn't my core skillset.

I leave the ability to compute a g vector to you but the real question is how accurate does it truly need to be? I think the answer is enough to know if the airplane is upright or inverted and is pitching towards blue or brown.

Tim Wescott · « **Reply #34 on:** December 22, 2021, 10:59:59 AM »

Quote from: Ken Culbertson on December 21, 2021, 03:27:11 PM

I should have read all of them! Good Job guys. Protecting us from ourselves is a noble endeavor!

Ken

Having a system that can do the full AMA pattern unattended is well within our grasp (and would be a fun robotics event, IMHO). Just clip a tether to a pole, walk out to the edge of the circle, push the "start" button, and watch the flight.

But that's not why I fly toy airplanes, so...

Ken Culbertson · « **Reply #35 on:** December 22, 2021, 04:08:47 PM »

Quote from: Tim Wescott on December 22, 2021, 10:59:59 AM

But that's not why I fly toy airplanes, so...

Me too!

Mark wood · « **Reply #36 on:** December 22, 2021, 06:07:44 PM »

Quote from: Tim Wescott on December 22, 2021, 10:59:59 AM

Having a system that can do the full AMA pattern unattended is well within our grasp (and would be a fun robotics event, IMHO). Just clip a tether to a pole, walk out to the edge of the circle, push the "start" button, and watch the flight.

But that's not why I fly toy airplanes, so...

Yup... That...

Igor Burger · « **Reply #37 on:** February 02, 2022, 10:55:13 AM »

Quote from: Howard Rush on December 18, 2021, 10:11:51 AM

My understanding is that the calibrate flight just learns what sideways acceleration to expect so changes in sensitivity don’t cause lap time changes. Igor?

I see I missed also this, yes exactly, it only sets "neutral" values in level flight, because sensitivity, what is actually nothing else only some multiplikator (gain), will magnify static offset and that means lap time will change after change of sensitivity. I use fixed sensitivity so I do not do calibration at all.

Igor Burger · « **Reply #38 on:** February 02, 2022, 10:56:48 AM »

Quote from: Brett Buck on December 14, 2021, 09:28:20 PM

Has anyone tried logging the fore/aft (X axis) of their 3-axis accelerometer? I think Igor only uses one axis of it, Y. I am curious what the acceleration looks like into and out of a corner.

Brett

I use X and Y. Do you have data already? I have recodred some flights if you did not get yet.

Igor Burger · « **Reply #39 on:** February 02, 2022, 11:02:07 AM »

Quote from: Tim Wescott on December 15, 2021, 05:04:00 PM

Yes, but it doesn't look right to me -- I'd expect a 2g peak-peak variation in the x axis in the loops.

Accelerometer does not "see" gravity, it ca only see how much prop pulls. So you can see 2g only in case that your regulator keeps constant speed, but while that regulator is based on measuring x axis variation which has to be controlled to see 2g by measured variation in x ... I am somehow lost already, simply it does not work like that

Mark wood · « **Reply #40 on:** February 02, 2022, 11:02:12 AM »

Quote from: Igor Burger on February 02, 2022, 10:56:48 AM

I use X and Y. Do you have data already? I have recodred some flights if you did not get yet.

I would be interested in seeing your data. Another question. What are you doing for filtering the incoming data?

Igor Burger · « **Reply #41 on:** February 02, 2022, 11:17:50 AM »

Quote from: Mark wood on February 02, 2022, 11:02:12 AM

I would be interested in seeing your data. Another question. What are you doing for filtering the incoming data?

I have inside relatively complex filter with shift register which reflects what is happening during last second of flight, I wrote it in another thread. Simply I spent 4 years tuning with several tricks and result is this, fortunately I had good test pilot

.

But I remember, in some cases it "keeps" power for short time (to cover lost energy in maneuver), sometimes cuts it early (to prevent acceleration), few some tricks wit AoA (because it wanted accelerate in every corner, what I did not like since my pipe time, but I remember one guy calling exactly for that) and some other minor, do not ask me exactly, I started in 2006 and it was finished 2010. Since then I did not touch it,because it work well for me

Tim Wescott · « **Reply #42 on:** February 02, 2022, 03:59:57 PM »

Quote from: Igor Burger on February 02, 2022, 11:02:07 AM

Accelerometer does not "see" gravity, it ca only see how much prop pulls. So you can see 2g only in case that your regulator keeps constant speed, but while that regulator is based on measuring x axis variation which has to be controlled to see 2g by measured variation in x ... I am somehow lost already, simply it does not work like that

I'd kinda figured out that the plane must be speeding up and slowing down with respect to the ground. I think there's a whole sub-thread in here to the effect of wondering what a real constant-speed flight would be like -- probably horrifying to anyone used to what we do now, but potentially better if you spend five years getting used to the feel of it, instead of trying to adjust it back to a "piped airplane" feel.

Igor Burger · « **Reply #43 on:** February 03, 2022, 03:27:45 AM »

Yes, it is possible to learn also constant speed (if physically possible, what is actually not with our models, fixed props, available power etc.). But:

1/ I do not think it is natural for human mind, we simply expect that object moving up will slow down and moving down will accelerate to some extent. What we have to is limit to extend that we have enough line tension on top, so we not need to fly too high level speed

2/ there are square figures with shorter top segment (I think Paul wrote it somewhere) and that needs slower speed on top of them to maintain "timing". Simply too strong effectivity will make problem there.

3/ it is not only pilot what have to be prepared for that, model reacts to power train changes also, it causes yaw and changes sensitivity of elevator, simply model flies differently with full thrust and full braking, changes of thrust must be gentle and expecting, that is why I do not like that boost in every corner

There is a good example. Richi K. He used only braking, no acceleration at all (he set timer values for only braking, acceleration was limited by Max value). So it is necessary to try and tune little bit. Therefore I always recommend to trim model at constant speed and then activate it slowly to the extent that it improves model properties. There is a point where it is already not helping anymore, that is reason why I think there is an optimum and it not need to keep really constant speed. But another truth is that I push it during the time higher and higher, so may you are right and I am learning to fly it closer and closer to constant speed.