News:



Advertise Here

  • November 12, 2019, 01:42:43 PM

Login with username, password and session length

Author Topic: Timer Software Logic  (Read 2188 times)

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Timer Software Logic
« on: July 31, 2019, 08:07:37 AM »
I am thinking to make my own active timer. The idea is to make one that will suit my needs and also if anyone else wants to follow in my foot steps that same timer can suit their needs.
The biggest hing is to deal with what type of logic, sensors circuits are necessary to accomplish that.
Some of my thoughts where to use a pitot tube with a pressure sensor that will detect the pressure via a pressure sensor to control speed of the plane. But I think the problem with it is high winds flying where constant air speed might not work, when the model flies in the wind it will want to slow down and vice versa, and we want a different kind of constant speed which is relative to the path of the model independent of the wind. So the second idea was to use an accelerometer/gyro to measure acceleration, in particular the centrifuge acceleration and orientation to output the motor throttle settings. I think this is the way to go but I am having a little trouble thinking of the mathematical logic that should be used. If it was just the centrifuge force it would be easy but it all changes when you add the gravity in the equation. If you consider the standard axis x (pointing forward) Y (pointing span wise) and Z (in the vertical plane) they all work together to point at the position and attitude of the model. The tricky stuff is to find common ground between them and here is where the mathematical logic comes in place.  With gyro  acclelerometers sensors you can read acceleration in all 3 axis and 3D orientation at all times. The microchip job is import the data from the sensor do the math and, in our case, output the throttle to the ESC.
What I would like to have in this thread is to brainstorm ideas for this mathematical logic, how to process the data received in to the throttle output.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #1 on: July 31, 2019, 09:56:52 AM »
This has been talked about a lot, here, and, before I got back into CL, on Stuka Stuntworks.

I'm pretty sure that the Igor Burger timer uses a single accelerometer that's active along the spanwise axis of the airplane (canonically it's the y axis -- if you want to minimize confusion when talking to aviation types, use the aviation vehicle frame of reference: x positive out the nose, y positive out the starboard wingtip, z positive out the bottom of the aircraft).  This gives an extra boost when you're above ground, but apparently this is not a Bad Thing.

From comments I've read, Igor went through pitot tubes and gyros before settling on the accelerometer, and he certainly feels that what he has works plenty good.  Rogerio Fiorotti has an inertial timer that uses a gyro, but I seem to remember someone mentioning one that uses an accelerometer.

I suggest that you start by digging through the archives here, and maybe reading Igor's and Rogerio's websites before you go and reinvent the wheel.  If you're still serious after all that, PM me -- I'm seriously considering open-sourcing the TUT hardware and software; the big TUT has a 3-axis gyro and a 3-axis accelerometer on it, and has software that's already sorted to talk to them.  (Not, I'm sad to say, software that manages to talk to the SD card, @#$%!)  I'd be especially interested if you've got some experience with embedded systems software -- I haven't had time to work on it (hence the not-yet-functioning SD card interface); I'd be happy to try to convince you to make it work the way I want it to!

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

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #2 on: July 31, 2019, 10:44:29 AM »
A large part of our hobby is exactly what you are doing but I have to agree with Tim.  Why reinvent the wheel.  I have been waiting for the TUT to become available instead of moving to Igor's system.

We all have our own ideas of when we want power added or taken away in the pattern.  Personally I would like to see some effort put into making our current technology more adaptable to us instead of us having to adapt to it, make it more affordable and more adaptable in the field.

I wish you luck in your quest for a better timer but IMHO there is also a danger that we are making our planes so easy to fly that "even a cave man can do it".   

I would be curious why Igor abandoned the airspeed indicator.  It think an argument can be made that actual airspeed is more important than ground speed for a CL plane anyway.

Ken
« Last Edit: July 31, 2019, 11:02:21 AM by Ken Culbertson »
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #3 on: July 31, 2019, 10:51:11 AM »
I kind of figured out that the way to go is to use an accelerometer gyro or a combination of both. The question is to find logic between the data retrieved and the relative position in flight.
I am not trying to reinvent the wheel but to make my own wheel, and learn something in the process. And by the way you know how much I am in to doing the same thing everyone does.
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: 736
Re: Timer Software Logic
« Reply #4 on: July 31, 2019, 11:00:22 AM »
Can you please place links here on anything you find out on this subject. I cant find anything on the development of the Igor or Fiorotti timers. I have no idea what TUT is.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Howard Rush

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6653
Re: Timer Software Logic
« Reply #5 on: July 31, 2019, 12:34:25 PM »
Figure out how to do a loop kill while you’re at it.
The Jive Combat Team
Making combat and stunt great again

Online Howard Rush

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6653
Re: Timer Software Logic
« Reply #6 on: July 31, 2019, 12:44:26 PM »
Can you please place links here on anything you find out on this subject. I cant find anything on the development of the Igor or Fiorotti timers. I have no idea what TUT is.


Go to embedded.com.  Search for the article “PID without a PhD”.
The Jive Combat Team
Making combat and stunt great again

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #7 on: July 31, 2019, 01:32:22 PM »
I have no idea what TUT is.

http://atomiczombieworkshop.com/tut/tut.html

... I have been waiting for the TUT to become available instead of moving to Igor's system. ...

I'm the guy developing the TUT, and I'm not sure that's the best idea!  It's not a lack of will -- it's that I've got way too many irons in the fire.

I kind of figured out that the way to go is to use an accelerometer gyro or a combination of both. The question is to find logic between the data retrieved and the relative position in flight.
I am not trying to reinvent the wheel but to make my own wheel, and learn something in the process. And by the way you know how much I am in to doing the same thing everyone does.

Pretty much the canonical way to do this is to use a Kalman filter to combine the accelerometer & gyro data with the fact that the airplane is orbiting around a (more or less) fixed point in space in a gravitational field with an acceleration of 9.81 meters per second2 downward.  I believe that the sensors in the TUT are accurate enough to do a pretty good job (within less than a meter, and less than a meter/second) of locating the aircraft, and my back-of-the-envelope calculations bear this out.  Brett Buck, who's a pretty bright guy, disagrees with me -- and really the onus is on me to get the Kalman filter written and give it a whirl.

(And note that the processor in the TUT was chosen to have enough horsepower -- barely -- to implement an on-line Kalman filter.  If it doesn't, well, the nice thing about being a laggard on the project is that there's faster processors in the same package).

The second part of the equation, though, is what do you *do* with the information?  In a past conversation with Igor, he mentioned that he felt he had at one point gotten the plane to fly at a dead steady speed in inertial space ("inertial space" in this case is pretty much "with respect to the ground").  He didn't like it -- it was too slow going downwind, too fast going upwind, and I believe that he didn't like the behavior on the up- and down-lines.  Paul Walker has also had issues with the Igor timer, as it comes, with slowing the plane too aggressively on straight down-lines, so that a 90 degree corner to level doesn't have enough "oomph" for him.

I'm pretty sure that even if the Kalman filter solution is perfect, there would still need to be some experimenting done to decide what to actually do with the results -- I suspect that people will have preferences about whether the speed should be goosed when the plane is on high, or screaming straight down, etc..  I further suspect (given that Igor seems to like Igor's default settings, and Paul tends to have his Igor timer set up at the extremes of some of the settings) that different pilots -- even experts -- are going to want different things.  People may even find that they want to have different tunings for calm conditions than for wind.
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

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #8 on: July 31, 2019, 01:48:23 PM »
http://atomiczombieworkshop.com/tut/tut.html

I'm the guy developing the TUT, and I'm not sure that's the best idea!  It's not a lack of will -- it's that I've got way too many irons in the fire.

No hurry, I am still about a 1/2 year away from getting my skills back to where I will need it to improve anyway.  I don't want to go through the learning curve unless I have to!

Ken
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #9 on: July 31, 2019, 03:10:34 PM »
This is kind of what I had in mind also, the Kalman filter solution.
I have a table that assumes constant speed, in this case you compare the angle with the horizontal and the acceleration in the Y direction, and if the two tables agree then you are good, else some adjustment has to be done. In theory this should work for rounds etc. In addition to that I was also thinking in using the Z and X accelerometer sensors to modify the base RPM, and this addition should complement for the squares triangle part of the program. This is kind of the general direction I am thinking of going right now.
https://m.eet.com/media/1112634/f-wescot.pdf Thaks
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Howard Rush

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6653
Re: Timer Software Logic
« Reply #10 on: July 31, 2019, 04:05:35 PM »
No hurry, I am still about a 1/2 year away from getting my skills back to where I will need it to improve anyway.  I don't want to go through the learning curve unless I have to!

Ken

You can find a couple TUTs in a Dallas pawn shop.
The Jive Combat Team
Making combat and stunt great again

Offline CircuitFlyer

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 172
    • www.circuitflyer.com
Re: Timer Software Logic
« Reply #11 on: July 31, 2019, 04:53:36 PM »
Hold on, before anyone drives themselves crazy trying to mathmaticaly combine the the outputs of several accelerometers and gyroscopes into something usable, look at 9_degree of freedom sensors, absolute orientation sensors, inertia measurement units and sensor fusion.  The hard work has already been done, for example: https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor.  This sensor is capable of outputting the models orientation in quaternions (Euler angles without gimble lock).  Which can be easily converted into usable axis-angles for our needs.  This sensor is very similar to the one in your smart phone.  I have run some tests on the above sensor with an Arduino Dev board and it seems to work really well.  The self calibration makes it real easy to use.

Paul
Paul Emmerson
Spinning electrons in circles in Mississauga, Ontario, Canada

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #12 on: July 31, 2019, 05:09:41 PM »
Hold on, before anyone drives themselves crazy trying to mathmaticaly combine the the outputs of several accelerometers and gyroscopes into something usable, look at 9_degree of freedom sensors, absolute orientation sensors, inertia measurement units and sensor fusion.  The hard work has already been done, for example: https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor.  This sensor is capable of outputting the models orientation in quaternions (Euler angles without gimble lock).  Which can be easily converted into usable axis-angles for our needs.  This sensor is very similar to the one in your smart phone.  I have run some tests on the above sensor with an Arduino Dev board and it seems to work really well.  The self calibration makes it real easy to use.

Paul

I ruled out using a magnetometer because of the proximity to electric motors blasting away, and having absolute orientation still doesn't tell you how fast you're going.
AMA 64232

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

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #13 on: July 31, 2019, 06:13:30 PM »
How did you solve the how fast are you going problem?
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #14 on: July 31, 2019, 06:30:32 PM »
How did you solve the how fast are you going problem?

Wrong tense -- the expectation is that I'll do that in the Kalman filter.

Igor Burger's timer just servoes on acceleration; the Rogerio Fioretti timer does it with angular rate.
AMA 64232

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

Online Bob Hudak

  • 2017
  • Trade Count: (0)
  • Captain
  • *
  • Posts: 417
Re: Timer Software Logic
« Reply #15 on: July 31, 2019, 07:16:49 PM »
TDM,
 SO THE TUT was developed by a fellar out west. If I recall his name was Tim. Dig thru the forums for TUT to get th rest of the story.
Bob
350838

Offline CircuitFlyer

  • Trade Count: (0)
  • Commander
  • ****
  • Posts: 172
    • www.circuitflyer.com
Re: Timer Software Logic
« Reply #16 on: July 31, 2019, 08:17:07 PM »
I ruled out using a magnetometer because of the proximity to electric motors blasting away, and having absolute orientation still doesn't tell you how fast you're going.

The initial bench testing I did actually surprised me how tolerant the magnetometer was of an operating electric motor. I could get within a few inches before things went wonky. You would have to test it for yourself to verify.

Control line is unique.  Negating any adverse roll or yaw, each unique orientation corresponds to only 1 point on the hemisphere. No reason why you couldn't calculate velocity from the location over time.  The sensor also outputs angular velocity, shouldn't that be enough?

Paul
Paul Emmerson
Spinning electrons in circles in Mississauga, Ontario, Canada

Online Ken Culbertson

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #17 on: August 01, 2019, 06:18:37 AM »
roll or yaw
If those can be measured then you have the basis for a trim mechanism.  That is if the rules don't consider trim tabs control surfaces.  More stuff we don't need but if we are going down that road, why not do it in a Cadillac instead of a scooter.

Ken
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #18 on: August 01, 2019, 09:02:55 AM »
First is what a great idea to just use the angular velocity directly from the sensor. For that the best I think will work is the gyro sensor, so the idea is to compare the angular velocity of the model and keep that constant. Do a calibration flight after you set the lap time, then use that angular velocity and have the processor match it, and if it increases throttle down and vice versa.  But I am also considering an accelerometer too to use data from there to modify the angular velocity if needed or desired. The idea of using the BNO0055 with the magnetometer disabled will be great too since it already does the output for you and I do not need to know what is the compass bearing.
Cadillac instead a Scooter is a good thing to have.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #19 on: August 04, 2019, 10:48:53 AM »
Let's assume that in level flight a line pull of 3g is sufficient.

If we want the same line pull overhead, we have to add 1g to the centrifugal acceleration. That means that we need about 30% more motor power overhead. This can be regulated using an acceleration sensor in the y-direction.

Without wind, this system works very well, I have implemented it in my own timer, using an 8 pin microchip, programmed in Assembler.

To make the PID regulation more versatile (and to improve wind compensation), I am rewriting the software in C++ for a cheap Arduino Nano.
If somebody is interested, I can give more details.

Regards,

Wolfgang

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #20 on: August 06, 2019, 07:56:29 AM »
For sure I am interested.
I explored the idea of using the Y direction accelerometer and I created a theoretical chart of angle of elevation and Y acceleration at that angle of elevation. The idea was to measure the Y multiply with what you usually get during level flight (calibration) and based on that information you know what angle with the horizontal. By comparing both the expected angle and the reading of the actual angle you can make a decision as for you are flying fast or too slow and output some throttle correction. This was kind of my first idea. But I think the Gyro already calculates the angle on all three axis so all we have to do is read that angle directly.
Each goal you meet is a moment of happiness
Happiness is the harmony between what you think and what you do. Mahatma Gandhi

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #21 on: August 06, 2019, 09:03:59 AM »
For sure I am interested.
I explored the idea of using the Y direction accelerometer and I created a theoretical chart of angle of elevation and Y acceleration at that angle of elevation. The idea was to measure the Y multiply with what you usually get during level flight (calibration) and based on that information you know what angle with the horizontal. By comparing both the expected angle and the reading of the actual angle you can make a decision as for you are flying fast or too slow and output some throttle correction. This was kind of my first idea. But I think the Gyro already calculates the angle on all three axis so all we have to do is read that angle directly.

If you dig up the discussions about this that have already been made on this forum (that's a strong hint) you'll find that using the gyro has already been tried.  The problem that Igor ran into using a gyro is that any yaw of the aircraft with respect to the lines mucks up the velocity calculation.  Low-pass filtering the yaw slows down the control loop.

All of this stuff has been answered!  If your goal is to fumble around making the same mistakes that other folks have made, then by all means proceed as you are.  If your goal is to build on the knowledge that's already been gathered and -- quite generously -- disseminated and commented on, then you may want to dig up the relevant threads.  It'll be a pain, but it'll be worth it.  If you can't find 'em, post a "how do I find these threads" thread.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #22 on: August 06, 2019, 11:23:23 AM »
TDM,

My goal is to keep the line pull constant over the complete hemisphere. A gyro cannot compensate for gravity, but an accelerometer can.
Whatever motor/propeller combination that can make the plane  fly fast enough to always achieve 3g at the handle, will do.
With "always" I mean climbing, diving and cornering, and that horizontally, overhead and in between.
I chose the Arduino Nano because it is small enough, and you need no hardware to program (except an USB cable..).
All kind of sensors can easily be connected.

Can you agree on the basic idea?

Regards,

Wolfgang

Online Ken Culbertson

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #23 on: August 06, 2019, 12:35:53 PM »
TDM,

My goal is to keep the line pull constant over the complete hemisphere. A gyro cannot compensate for gravity, but an accelerometer can.
Whatever motor/propeller combination that can make the plane  fly fast enough to always achieve 3g at the handle, will do.
With "always" I mean climbing, diving and cornering, and that horizontally, overhead and in between.
I chose the Arduino Nano because it is small enough, and you need no hardware to program (except an USB cable..).
All kind of sensors can easily be connected.

Can you agree on the basic idea?

Regards,

Wolfgang
I am curious what you hope to gain by having equal line tension through out the pattern?  There are a bunch of places in the pattern where the change in tension tells me if I have things right.  I can "feel 45 degrees for the outside squares and cloverleaf (42).  I know I am centered with the wind through tension, I can feel 90 degrees through the lines.   I would not want equal tension but that does not mean that you shouldn't.  Just curious why.

Ken
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Offline Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #24 on: August 06, 2019, 02:07:03 PM »
Ken,

by  never having more line tension than needed, diving speed will be reduced, and  energy will be saved, so  a lighter battery can be used.

Regards,

Wolfgang

Online Ken Culbertson

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #25 on: August 06, 2019, 03:40:12 PM »
Ken,

by  never having more line tension than needed, diving speed will be reduced, and  energy will be saved, so  a lighter battery can be used.

Regards,

Wolfgang
Perhaps, but I think I would rather have the variable feel.

Good Luck - Ken
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #26 on: August 06, 2019, 06:24:49 PM »
Perhaps, but I think I would rather have the variable feel.

Good Luck - Ken

At least at one point Paul Walker had his Igor timer set up so that it had limited control authority on the throttle in one direction -- I can't remember if it was up or down.  It was specifically because he didn't want the airplane to be "on the rails" speed wise.

Something to remember is that any system that servos the airplane speed using inertial sensors (gyros and accelerometers) is going to hold the airplane speed constant in inertial space (essentially ground speed).  Done perfectly, that means that in the wind the airspeed will be lower going downwind, and higher going upwind.  This is probably OK to a certain extent, but at some point you'll run out of lift.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #27 on: August 07, 2019, 06:45:37 AM »
Tim,

You are right regarding the gyro, it can only keep the velocity constant. But an acceleration sensor can adapt the velocity to keep the line pull constant.

The disadvantage of an acceleration sensor in level flight, as you pointed out, is that the airspeed would be reduced downwind. But there are tricks  to to compensate this, al least partially.

Reading your excellent article "PID without a PhD" , our plane is the "plant" in figure 1. So, what remains to be done is to find the best constants for  PID regulation of the line pull.

Regards,

Wolfgang

Offline dave siegler

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 936
  • sport flier
    • Circlemasters Flying club
Re: Timer Software Logic
« Reply #28 on: September 22, 2019, 03:00:44 PM »
so how about something simple, consider just Feed forward based on acceleration changes and position. 

I think that is how the indoor control line systems work.  No gyro, just and acceleromoter and a look up table for how much feed forward. 

might this do it? 

https://www.adafruit.com/product/2019?gclid=Cj0KCQjwt5zsBRD8ARIsAJfI4BhZ50LvoP-MMHf4Mdjbwj78FNmmFhh0uBiEKsA6ozSE2zfhDZEGcN0aAj2AEALw_wcB
Dave Siegler
NE9N extra class
AMA 720731
EAA 1231299 UAS Certificate Number FA39HY9ML7  Member of the Milwaukee Circlemasters. A Gold Leader Club for over 25 years!  http://www.circlemasters.com/

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #29 on: September 22, 2019, 03:30:40 PM »
Sorry for the delayed response!

Tim,

You are right regarding the gyro, it can only keep the velocity constant. But an acceleration sensor can adapt the velocity to keep the line pull constant.

It can keep the outward acceleration constant -- but in a stiff wind, and with an unfortunately trimmed airplane, it wouldn't keep the pull constant.  I frankly do not know if you would want to go for the constant outward acceleration and trim the airplane, or if you'd want to try other means of compensation.

Reading your excellent article "PID without a PhD" , our plane is the "plant" in figure 1. So, what remains to be done is to find the best constants for  PID regulation of the line pull.

If you hook an Igor timer to a servo, hold the accelerometer in your hand, and move things around while watching the servo, you can see that he's just using proportional on the acceleration, or possibly proportional and a bit of differential (but if so, not much).  He's not using PID, unless he has strict limits on integrator windup.

so how about something simple, consider just Feed forward based on acceleration changes and position. 

I think that is how the indoor control line systems work.  No gyro, just and acceleromoter and a look up table for how much feed forward. 

might this do it? 

https://www.adafruit.com/product/2019?gclid=Cj0KCQjwt5zsBRD8ARIsAJfI4BhZ50LvoP-MMHf4Mdjbwj78FNmmFhh0uBiEKsA6ozSE2zfhDZEGcN0aAj2AEALw_wcB

Except that it's not feedforward, because changes to the motor speed affect the outward acceleration, which closes the loop.
AMA 64232

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

Offline dave siegler

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 936
  • sport flier
    • Circlemasters Flying club
Re: Timer Software Logic
« Reply #30 on: September 22, 2019, 03:52:46 PM »
Ok not classical feed forward.  But the indoor planes flown in Europe, if believe are open loop. 

Igor made some comment that feed forward was enough control and on these little ones a simple position based boost was sufficient. 

this will be a winter project for me, as we have some special requirements, and there is no contests foe this in the US. 

Jut wondered what sensor he used.   
Dave Siegler
NE9N extra class
AMA 720731
EAA 1231299 UAS Certificate Number FA39HY9ML7  Member of the Milwaukee Circlemasters. A Gold Leader Club for over 25 years!  http://www.circlemasters.com/

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #31 on: September 22, 2019, 08:06:39 PM »
Ok not classical feed forward.  But the indoor planes flown in Europe, if believe are open loop. 

Igor made some comment that feed forward was enough control and on these little ones a simple position based boost was sufficient. 

this will be a winter project for me, as we have some special requirements, and there is no contests foe this in the US. 

Jut wondered what sensor he used.

You'd need to check with him.  I was probably a bit hasty -- if the accelerometer is measuring inward acceleration, then it's essentially measuring speed + gravity.  If the accelerometer is measuring the acceleration crossways to the aircraft then it would be independent to the aircraft speed, at least to a first-order approximation.

I'm not sure what Igor is doing with his indoor planes -- I had been under the impression that he was using the same setup as for F2B, but I could easily be mistaken.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #32 on: October 08, 2019, 08:20:25 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

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #33 on: October 08, 2019, 10:02:32 AM »
Hey Wolfgang:

You may want to start a separate thread on this.

As a rule of thumb, the starting point for the derivative gain is about as much bigger as proportional gain as the proportional is bigger than integral -- i.e., kd = kp^2 / ki.  Given how far you are from that, I'm wondering if your derivative gain is doing anything at all (or if you want to even try going there).

Before you launch into anything else, try to control the noise going into the error term.  This means making sure that the sensor is located somewhere that isn't catching a mechanical resonance (and isn't flopping around), and it especially means that you want to sample at a fixed rate.  If you're using an accelerometer chip that gives you a reading at a constant rate, make sure you're catching all of the readings.

Past that, you can band-limit a derivative term (this basically makes your derivative + proportional into a lead-lag controller, which some people will insist isn't PID -- control systems engineers can get into as many pointless arguments as the rest of us).  But - it requires significant control system expertise to apply it correctly, and it's something that would need to be set for each plane/motor/ESC/prop combination individually.

If you really want to go there:


float da = 0.1;  // derivative bandlimit gain.  Smaller is slower.  da = 1.0 means you don't have any band limit.  Don't go over 1.0.

derivative = da * (error - d_state);
d_state = d_state + derivative;
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #34 on: October 09, 2019, 08:01:41 AM »
Hello Tim,
thanks for your competent answer. Based on your comments I made an Excel spreadsheet to simulate the loop, discovering that it is the integral that overflows. So, your assumption that the derivative is not effective at all, is correct.

A solution could be to limit the integral value. But to what extent? To plus/minus the maximum expected error? Can you suggest a value?

Thanks in advance,

Wolfgang

Online Howard Rush

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6653
Re: Timer Software Logic
« Reply #35 on: October 09, 2019, 02:28:07 PM »
I may not know what I'm talking about, but if the proportional gain is 31000 times the integral gain and the integrator is overflowing, I would think something is wrong.  Why would you have an integrator anyhow?

My analog mind says the transfer function of your controller is RPM command (s) / acceleration error (s) = Ki/s2 + Kp/s + Kd .  Is that correct?  Did I miss a feedback somewhere?

Tim, if you explain this, please type slowly so I'll understand.
The Jive Combat Team
Making combat and stunt great again

Offline Dean Pappas

  • Moderator
  • Trade Count: (0)
  • Admiral
  • *****
  • Posts: 1195
  • Welcome to the Stunt Hanger.
Re: Timer Software Logic
« Reply #36 on: October 09, 2019, 03:31:44 PM »
Wrong tense -- the expectation is that I'll do that in the Kalman filter.

Igor Burger's timer just servoes on acceleration; the Rogerio Fioretti timer does it with angular rate.

Expectation! Now that's funny #^
Regards,
 Dean Pappas
Dean Pappas

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #37 on: October 09, 2019, 03:58:34 PM »
... your assumption ...

Conclusion.  Conclusions are more classy than assumptions.

A solution could be to limit the integral value. But to what extent? To plus/minus the maximum expected error? Can you suggest a value?

Do a search on integrator anti-windup.  It's a known problem.  Note that unless your spreadsheet had the system working in closed loop your actual integrator may not overflow (how can you do that with floating point math?), but it still may wind up.

To be self-serving, start looking here in your search.

I may not know what I'm talking about, but if the proportional gain is 31000 times the integral gain and the integrator is overflowing, I would think something is wrong.  Why would you have an integrator anyhow?

Without knowing the sampling rate it's hard to say if the ratio between proportional and integral gain is reasonable or not -- the way that Wolfgang has written the algorithm the continuous-time integrator gain is the stated ki times the sampling rate.

My analog mind says the transfer function of your controller is RPM command (s) / acceleration error (s) = Ki/s2 + Kp/s + Kd .  Is that correct?  Did I miss a feedback somewhere?

Tim, if you explain this, please type slowly so I'll understand.

Sorry, I'm on break, need to type quick.

You're off by a factor of 1/s, and some sampling rates.  If the sampling interval is T, then it's Ki / (T * s) + Kp + (T * s) * Kd/sampling_weirdness, where the "sampling_weirdness" term doesn't matter much unless you're a real control geek (or your system starts oscillating really, really fast due to too much gain at high frequencies -- then it matters, or you should use a bandlimited derivative).

I'm not sure if Wolfgang has an integrator to try to get the speed just exactly right (which is a debatable goal) or simply because he's cribbing off of some established "how to write PID code" article.  It's not a bad thing to try, if you can get the integrator response fast enough that you don't come down from on high and then go too fast for half a lap (or worse, have the motor goosed on the top line of the hourglass, and then really be charging downward to that 4th turn!!).
AMA 64232

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

Online Howard Rush

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 6653
Re: Timer Software Logic
« Reply #38 on: October 09, 2019, 11:52:25 PM »
Oh, I forgot sampling rate.  Of course. 

You're off by a factor of 1/s...

Looks like there's another integrator: pos=pos+dpos

The Jive Combat Team
Making combat and stunt great again

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #39 on: October 10, 2019, 12:16:38 AM »
Oh, I forgot sampling rate.  Of course. 

Looks like there's another integrator: pos=pos+dpos

AAAAH!  I missed that.  Wolfgang, take that out.  You do NOT want a double integrator in there!  One is enough, or possibly more than enough.

Unless you mean "pos" to be a rough estimate of the airplane position, and not the commanded RPM.  But if you do mean for "pos" to command RPM -- take out that last integrator step, and just have "pos" be the sum of the P, I and D terms.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #40 on: October 10, 2019, 04:45:25 AM »
Gentlemen,

Thanks for the correction. That means, that, when the error is zero for some time, the pulse length pos is given only by the product of ki and the integrative term. Then, the integrative term can be allowed to be between maxpos/ki and minpos/ki.
Then the loop looks as follows:


     // PID loop
                                 
  maxint=maxpos/ki; 
  minint=minpos/ki;                             
  error= target-Readsensy();                        //deviation from target 3 g linepull
  digitalWrite(select, LOW);                        //set sensor sensitivity
         integral=integral+error;
         if (integral>maxint) {integral=maxint;};
         if (integral<minint) {integral=minint;};
         
         derivative=error-last_error;
         
  pos=round(kp*error)+round(ki*integral)+round(kd*derivative);  //new rpm
 
  if (pos > maxpos){pos=maxpos;};
  if (pos < minpos) {pos = minpos;};
  last_error=error;                       //for derivative calculation
==============

Seems to work (at least with a servo) with
kp=4.04
ki=0.16
kd=2.54

Is there a better test method than with a servo?

Regards,

Wolfgang


Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #41 on: October 10, 2019, 01:23:15 PM »
Is there a better test method than with a servo?

Because you're operating open-loop, possibly not.  Tuning the system is going to depend on the actual airplane performance; that either depends on doing a whole bunch of modeling, or on just going out and flying.

If you don't have a background in control theory, read that paper I linked to -- it has the accepted millwright's seat-of-the-pants method for tuning a PID controller.  It'll probably get you as close as you can without actually learning all the math, and instrumenting your code to capture the aircraft dynamics.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #42 on: October 10, 2019, 01:48:10 PM »
My background in control theory dates from the early seventies, when we had only pneumatic controllers. ;.)
Digging in the theory, I found a better approach: Set a nominal pulse length (for the average rpm), and use the PID to calculate the needed variation to that rpm.

Result:




   // PID loop

//maxint=maxpos/ki; 
 //minint=minpos/ki;                             
 error= target-Readsensy();                        //deviation from target 3 g linepull
 digitalWrite(select, LOW);                        //set sensor sensitivity

 if(-3 <error <3)
       { integral=integral+error;};
//       if (integral>maxint) {integral=maxint;};
//         if (integral<minint) {integral=minint;};

        derivative=error-last_error;

 dpos=round(kp*error)+round(ki*integral)+round(kd*derivative);  //rpm change
 pos=throttle + dpos;                //new rpm

 if (pos > maxpos){pos=maxpos;};
 if (pos < minpos) {pos = minpos;};
 last_error=error;                       //for derivative calculation

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

const float kp=4.04;                //pid proportiona factor
const float ki=0.005;                //pid integrative factor
const float kd=2.04;                //pid derivative factor
//      int maxint;                   //upper limit intergrative term
//      int minint;                   //lower limit integrative term
     int throttle=100;             //initial value of rpm, max 128
            =======================

Tuning will now be don on the field, I need only a small window$ laptop and an USB cable.

Regards,

Wolfgang


Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #43 on: October 17, 2019, 10:29:54 AM »
How do you compensate for the change in G depending on the angle elevation? In level flight you get around 3G's. But overhead at same speed you have 2G's.
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: 736
Re: Timer Software Logic
« Reply #44 on: October 17, 2019, 10:36:34 AM »
What about using the the angular velocity output from the BNO055 and hold that. In addition you could have some modifiers to add a little and take away a little in dives or climbs. 

« Last Edit: October 18, 2019, 02:38:47 PM 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 Wolfgang Nieuwkamp

  • Trade Count: (0)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #45 on: October 19, 2019, 10:31:33 AM »
The timer uses the acceleration sensor to keep the line pull always at 3g. That means, that overhead the plane flies at the speed which generates 4 g outwards. Adding the inward 1 g due to gravity, the line pull stays at 3g.
Of course, the motor/prop combo has to be strong enough...


Regards,
Wolfgang.

Online Tim Wescott

  • 2016 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 11368
Re: Timer Software Logic
« Reply #46 on: October 19, 2019, 01:18:59 PM »
What about using the the angular velocity output from the BNO055 and hold that. In addition you could have some modifiers to add a little and take away a little in dives or climbs.

If you just use the z (yaw) axis, then you need to take care that movement in the pitch axis does not bleed into it, or maneuvers will be taken as changes in speed (you have the same problem with the y (spanwise) axis with an accelerometer, of course).

In a discussion I recall from a Good Long Time Ago, it was pointed out to me that holding the aircraft too tightly to a constant speed in inertial space\* makes it go too fast on high -- Wolfgang's would make it go even more excessively fast.

But -- one thing that I have not pinned down is if the top pilots who don't want it going "too fast" up top dislike that behavior because they've got decades of experience flying slimers that just naturally slow down up there and could fly even better with the aircraft locked into one speed in inertial space, or if it's because it's really a bad idea to control the plane that way.

One argument that makes sense to me on not keeping the airplane's forward speed steady in inertial space is that in a strong wind you're going to really have a lot of control authority, and could conceivably be falling out of the sky on the downwind legs because of lack of airspeed.  I need to fly a really nicely speed-controlled airplane to know for myself if this is an issue (I'm expecting the answer will be "yes", or possibly even "yes, now where will I find the time to build another airplane?").  An obvious solution is to put a minimum on the speed command to the ESC, so that on downwind legs (and on the downward legs of the squares, which I recall Paul Walker mentioning was too slow when his Igor Burger timer was set really aggressively) the airplane does not slow down too much.

\* For the purposes of this discussion, "Inertial space" = according to the IMU.  It really means something complicated and physics-y having to do with some guy with white hair and elevators, but it basically means ground speed.  I could just say "relative to the ground", but I did aerospace-ish sort of stuff for a while where it mattered, and it has stuck.
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)
  • Lieutenant
  • ***
  • Posts: 116
Re: Timer Software Logic
« Reply #47 on: October 20, 2019, 03:51:22 AM »
Tim,

my system will not allow any excessive speed.
Please look at the drawing:


Lets assume a target line pull (without wind) of 3g.
If you fly at an elevation angle of 45°, regardless of the direction, the plane speed will be adapted to generate 3,7 g in the outward direction.
Any plane speed increase, for example when diving, will be compensated by reducing the motor revolution speed.

For an additional gyro I see no useful application.

Regards,

Wolfgang

Offline TDM

  • Trade Count: (0)
  • Captain
  • *****
  • Posts: 736
Re: Timer Software Logic
« Reply #48 on: October 21, 2019, 10:01:56 AM »
Wolfgang that is wrong. There is a vector addition. Note the vector arrows point in opposite direction, and you must subtract not add. That should make sense as the line tension doesn't increase ever.
Amusing same speed all around In horizontal flight there is around 3Gs pull (assuming about 70'and 5.3s lap time) at the top (overhead) you have 3-1 which ends up 2Gs, at 45 you have 3-.707=2.293Gs'.
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

  • 2019 supporter
  • Trade Count: (0)
  • Admiral
  • *
  • Posts: 1952
Re: Timer Software Logic
« Reply #49 on: October 21, 2019, 01:17:45 PM »
Refresh my memory as to what we are trying to solve here?  Is it equal line tension through out the pattern?  If so I have to ask why?  Isn't a constant speed more desirable than constant line tension?  You can't have both unless you want to play with induced yaw.  Are you trying to make the line tension the same at the last intersection of the overhaead 8 as it is on the second corner of the reverse wingover?

Having said that I applaud you for advancing the technology, I just don't see the practical application.

Ken
AMA 15382
If it is not broke, don't fix it.
If it is broke, replace it.
USAF 1968-1974 TAC

Tags:
 


Advertise Here