News:


  • March 28, 2024, 04:55:16 PM

Login with username, password and session length

Author Topic: Timer Software Logic  (Read 10380 times)

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #50 on: October 21, 2019, 02:44:51 PM »
Ken,

when flying electric you want to save energy. That means, to fly only as fast as necessary. Constant speed is a waste of energy, because when flying level you fly as fast as you need to when flying overhead, fighting gravity.
That is the reason for having only 3g under all circumstances.

TDM, please realize that the acceleration sensor only measure the force component in the span wise direction, y.
To help you to understand the system, I did redraw my sketch, adding vectors. Hope this helps.
Regards,

Wolfgang


Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #51 on: October 21, 2019, 04:45:36 PM »
Constant speed with some modifiers from that. I understand that when you use an accelerometer and set constant G force to achieve constant-ish speed would be the wrong approach unless you know what is the angle elevation of the plane in relationship to the horizontal. I fully understand that but your vector addition is not correct. What I was saying is if speed is constant then the pull on handle is dependent on the  angle the plane makes with the level ground. Gpull on handle=Gmax horizontal flight-1G x sin α (where α is the angle with the horizontal).

At horizontal (0)     Gactual=3G-Gsin0=3G
Overhead               Gactual=3G-Gsin90=3G-1G=2G 
At 45                     Gactual= 3G-Gsin45=3G-.7G=2.3G.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #52 on: October 21, 2019, 04:59:13 PM »
My goal is to be able to fine tune the flight to my liking. That means: to be able to customize take off power, landing power, to be able to get mostly constant speed but also be able to customize the up line and down line speeds lights etc.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Ken Culbertson

  • 24 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6036
Re: Timer Software Logic
« Reply #53 on: October 21, 2019, 05:38:13 PM »
Ken,

when flying electric you want to save energy. That means, to fly only as fast as necessary. Constant speed is a waste of energy, because when flying level you fly as fast as you need to when flying overhead, fighting gravity.
That is the reason for having only 3g under all circumstances.

I am not trying to be difficult but wouldn't having constant tension require you to have constant speed?  Only airspeed and line length control how many g's you are pulling at a given elevation of which only airspeed is variable.  Are you suggesting that you want to increase airspeed to compensate for gravity as the elevation increases?
All of this to save an ounce or two on a battery?

Ken
AMA 15382
If it is not broke you are not trying hard enough.
USAF 1968-1974 TAC

Offline Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 12804
Re: Timer Software Logic
« Reply #54 on: October 21, 2019, 06:27:13 PM »
I am not trying to be difficult but wouldn't having constant tension require you to have constant speed?  Only airspeed and line length control how many g's you are pulling at a given elevation of which only airspeed is variable.  Are you suggesting that you want to increase airspeed to compensate for gravity as the elevation increases?
All of this to save an ounce or two on a battery?

So, first, he's using an IMU, so he can't go for constant tension -- just constant inward acceleration.  That's different in that upwind, if speed is maintained, the line tension is the difference between the force needed to keep the plane going in a circle and the force imparted on the aircraft by the wind.

And second, no -- the IMU can't tell the difference between the acceleration due to gravity and the acceleration due to the inward pull of the lines.  So overhead you'd go faster (Igor Burger's setup must have this too; I'm not sure how or if he counters it).

If you start out at 3g (around 5.2-ish laps on long-ish lines) you'd have to go about 15% faster up top.  I'm not sure if I'd like that -- but Wolfgang will find out, and report back.
AMA 64232

The problem with electric is that once you get the smoke generator and sound system installed, the plane is too heavy.

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #55 on: October 22, 2019, 02:18:53 AM »
Gentlemen,

Yes, I like to go faster overhead than going down during the hourglass.

The wish to have constant speed IMHO is a remnant from IC times, where you had either 4-2-4 or constant rpm with a pipe. And blunt leading edges to prevent speeding up.

By the way, TDM and Ken, what you you mean by "speed"? RPM is not the same as flying speed. With constant RPM you will go faster diving, and slower climbing. That is the reason for my development.

Tim is absolutely right in that my system does not account for wind effects. I have partially solved that by flying horizontal faster than needed for 3g. Another solution would be to measure airspeed with a small propeller at the wingtip, but I have abandoned that, too complex.

 To be able to finetune RPM I will use an Arduino Nano, which is easy to program, cheap, and can handle all kind of sensors.

Regards,

Wolfgang

Online Ken Culbertson

  • 24 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6036
Re: Timer Software Logic
« Reply #56 on: October 22, 2019, 07:18:46 AM »
Gentlemen,

Yes, I like to go faster overhead than going down during the hourglass.

The wish to have constant speed IMHO is a remnant from IC times, where you had either 4-2-4 or constant rpm with a pipe. And blunt leading edges to prevent speeding up.

By the way, TDM and Ken, what you you mean by "speed"? RPM is not the same as flying speed. With constant RPM you will go faster diving, and slower climbing. That is the reason for my development.

Tim is absolutely right in that my system does not account for wind effects. I have partially solved that by flying horizontal faster than needed for 3g. Another solution would be to measure airspeed with a small propeller at the wingtip, but I have abandoned that, too complex.

 To be able to fine tune RPM I will use an Arduino Nano, which is easy to program, cheap, and can handle all kind of sensors.

Regards,

Wolfgang
I think that we can all agree that there are places in the pattern where we would like the plane to speed up or slow down.  I doubt we would all agree where those places should be and in my case they change with wind.  I think we might just be calling the same thing by different names.  I applaud your efforts.  The future of our sport is definitely electric for a lot of reasons, some of which I agree with, some I don't but never the less they are going to win out.  Anything that advances affordable technology is a good thing.

Ken
AMA 15382
If it is not broke you are not trying hard enough.
USAF 1968-1974 TAC

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #57 on: October 22, 2019, 08:44:49 AM »
The way I want to implement this will actually translate in to constant ground speed. By keeping the angular velocity constant and because the radius doesn't change then the speed magnitude doesn't change either. When the wind blows the model will have greater air speed when it flies in to the wind and lees when the wind is behind but in reference to the pilot and ground it will be constant. After i manage to do this I will introduce some modifiers for climb or dive. 
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #58 on: October 22, 2019, 09:05:46 AM »
Yes TDM, you nailed down the basic problem: When the wind is behind, the airspeed would become too low. I counteract that effect by flying faster, i.e. 3.1 g, when flying horizontal.
When you find a better solution, please let us know.

Regards,
Wolfgang

Offline Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 12804
Re: Timer Software Logic
« Reply #59 on: October 22, 2019, 09:59:51 AM »
Another solution would be to measure airspeed with a small propeller at the wingtip, but I have abandoned that, too complex.

Or a small Pitot/static tube mounted on a LE somewhere, outside of the prop blast.  There are some suitable, if kind of expensive, sensors out there -- the rest of the system would involve your Arduino, some brass tubing, and some fuel tubing: https://www.digikey.com/products/en/sensors-transducers/pressure-sensors-transducers/512?k=pressure&k=&pkeyword=pressure&sv=0&pv144=1234&pv144=1247&pv144=1213&pv144=924&pv144=926&pv144=925&pv144=927&pv144=985&pv144=1203&pv144=989&sf=0&FV=218%7C4%2C1877%7C2%2C1877%7C5%2C-8%7C512&quantity=&ColumnSort=1000011&page=1&stock=1&nstock=1&pageSize=25

AMA 64232

The problem with electric is that once you get the smoke generator and sound system installed, the plane is too heavy.

Online Ken Culbertson

  • 24 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6036
Re: Timer Software Logic
« Reply #60 on: October 22, 2019, 11:08:21 AM »
The way I want to implement this will actually translate in to constant ground speed. By keeping the angular velocity constant and because the radius doesn't change then the speed magnitude doesn't change either. When the wind blows the model will have greater air speed when it flies in to the wind and lees when the wind is behind but in reference to the pilot and ground it will be constant. After i manage to do this I will introduce some modifiers for climb or dive.
I think I would welcome this approach in level flight and the round maneuvers but I don't think I would adjust easily to the rapid changes it would produce in the cornered maneuvers.  I use the simplest of setups and I have become accustom to constant RPMs.  Having a little boost entering the RWO or OH8 would be nice but I am not convinced it would be much better than gently whipping into those corners.  Having it slow down on the downsides of the RWO and HG would be nice but then there is the downside of having it accelerate on the upward paths which, in the case of the hourglass will translate into too much speed for me.  The 2nd corner of the RWO and the top corners of the hourglass are pattern busters and I really don't like going into them too fast.

One of the problems I see with constant ground speed is that the controls will respond differently at different speeds.  With constant RPM you are (in theory) flying as close to constant airspeed as you can which keeps the control response about the same.  I suspect you will have some hunting to deal with, especially if the thrust alignment is not perfect.

I think the ultimate solution might be a miniature Red Bull pilot in the cockpit LL~
« Last Edit: December 13, 2019, 12:08:42 PM by Ken Culbertson »
AMA 15382
If it is not broke you are not trying hard enough.
USAF 1968-1974 TAC

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #61 on: October 22, 2019, 11:38:48 AM »
Tim,
the problem is not the differential pressure transducer, but the pitot tube. I'm afraid that it is too sensitive for different angles of attack, that is why I considered the small prop (that will wear out...).
Regards,

Wolfgang

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #62 on: December 11, 2019, 08:32:55 AM »
For my new timer project on an Arduino Nano, I am working on the PID regulation of the line pull in y direction.

I am testing the program with a servo instead of a motor. It works, but I would like to increase the derivative ki factor.

Any suggestions to make the loop less sensitive to noise?

Regards,

Wolfgang.

==========================

Program excerpt:

float kp=3.15;
float ki=0,0001;
float kd=3.04;
                    // PID loop

  error= target-Readsensy();        //deviation from target 3 g linepull in y direction
 
  integral=integral+error;
  derivative=error-last_error;   
                  //calculate correction dpos ;    pos => rpm
         
  dpos=round(kp*error)+round(ki*integral)+round(kd*derivative);
 
  pos=pos+dpos;                          //new rpm
 
  if (pos > maxpos){pos=maxpos;};
  if (pos < minpos) {pos = minpos;};

  last_error=error;                       //for dervative calculation
 

                  //end loop



I have some questions. For PID to work you need to work with some kind of function. What is the actual function that you use? Or you do not use a function and just use the coefficients. The question is

"integral=integral+error;" what do you use for integral? Integral of what function? Or is this some part of a library? What transfer function you use for the "Plant"?
 
« Last Edit: December 11, 2019, 11:25:33 AM by TDM »
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Offline Howard Rush

  • 22 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 7805
Re: Timer Software Logic
« Reply #63 on: December 11, 2019, 10:49:59 PM »
Put some lift in your vector diagram.
The Jive Combat Team
Making combat and stunt great again

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #64 on: December 13, 2019, 09:21:18 AM »
Howard,

my sketch applies for flying on a great circle, for example during a wingover. Then you need no lift.
Lift will always be perpendicular to the wing. The y-sensor only measures in the direction to the tip, so it will not register lift.

TDM,

There is no real function, I just try to reach the target centrifugal acceleration.
In the meantime I went back using a simple proportional approach.  Since I want a minimum airspeed during horizontal flight, I added an rpm sensor to the Arduino. Until now I can regulate the minimum rpm during horizontal flight at +/- 400 rpm. Flight test have not been made, waiting for better weather...

Regards,

Wolfgang

Offline Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 12804
Re: Timer Software Logic
« Reply #65 on: December 13, 2019, 01:29:23 PM »
... I added an rpm sensor to the Arduino. ...

Can you share what you did?  Maybe post a schematic?
AMA 64232

The problem with electric is that once you get the smoke generator and sound system installed, the plane is too heavy.

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 198
Re: Timer Software Logic
« Reply #66 on: December 13, 2019, 02:47:57 PM »
Tim,

here is a quick sketch.



The filter/schmitt-trigger gives one pulse per commutation.
The white AUX wire on my Castle ESC`s did not work....
The x- reading is only used to determine horizontal flying.

Regards,

Wolfgang

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #67 on: December 16, 2019, 06:39:03 AM »
OK thanks so basically you tune the PID based on real time experimentation.
I finished the first program and proved the stuff on bread board with a MKR Zero board. Next is to transition to the Arduino Nano where the pin out is a little different. This was exciting.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Offline Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 12804
Re: Timer Software Logic
« Reply #68 on: December 16, 2019, 12:16:16 PM »
OK thanks so basically you tune the PID based on real time experimentation.

The "millwright" way is to adjust the PID parameters in a logical step-by-step fashion that gives a decent compromise between robustness and ease of tuning (this is what I lay out in "PID Without a PhD"), but doesn't let you prove that things are robust, or necessarily get you the very best possible tuning.  My suspicion is that well over 90% of all the control loops in the world that aren't just on/off loops are tuned by this or some other seat of the pants method -- and most of those work well, so who's to complain?

The "aerospace" (and academic) way is to take careful measurements of the system and develop a model, or make even more careful calculations ahead of time and develop a model, and then develop a tuning (and sometimes a fancier controller than just a plain ol' PID) from that model. IMHO this isn't necessary here, although if everyone jumps on the bandwagon it may give someone an advantage in five or ten years to have a tighter, model-based tuning.

Note that taking the necessary measurements are beyond the capabilities of timers that are currently on the market (not even the TUT, because I need more spare time dangit!).
AMA 64232

The problem with electric is that once you get the smoke generator and sound system installed, the plane is too heavy.

Offline Howard Rush

  • 22 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 7805
Re: Timer Software Logic
« Reply #69 on: December 18, 2019, 04:36:39 PM »
Note that taking the necessary measurements are beyond the capabilities of timers that are currently on the market (not even the TUT, because I need more spare time dangit!).

So buy an artificial tree and get to work on the DataTUT.
The Jive Combat Team
Making combat and stunt great again

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 844
Re: Timer Software Logic
« Reply #70 on: December 19, 2019, 06:50:26 AM »
 I created two pieces of code.
 The first one that is finished is the code for a simple timer. This "simple" time has a custom take off ramp up of RPM to a custom take off RPM followed by a main flight RPM with gain (if desired), custom land parameters throttle down followed by constant throttle and shut down and LED lights warning before the motor starts and before land starts.
 The second one that is finished is the code for the accelerometer/gyro timer. This one time has a custom take off ramp up of RPM to a custom take off RPM followed by a main flight RPM where the throttle is driven by sensors followed by custom land parameters throttle down followed by constant throttle and shut down and LED lights warning before the motor starts and before land starts.
Many thanks to all who shared their knowledge.
Another thing that became obvious is that even though someone has no knowledge about programming knowledge if you put your head to it you can accomplish anything.

The next steeps are to run the new timers (weather pending) on a test bed and verify the program.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Offline Howard Rush

  • 22 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 7805
Re: Timer Software Logic
« Reply #71 on: December 19, 2019, 11:35:30 AM »
Rather than a slowdown at the end of the flight, I’d have it do a loop kill. That way you can choose where you land relative to the wind. That’s not legal for F2B, so you’d need something else for that case.
The Jive Combat Team
Making combat and stunt great again


Advertise Here
Tags:
 


Advertise Here