Brand New Products from Kontronik

[jamin_00]

Originally Posted by DannyvG

would be nice if they made their own predictive governor.
Just have either sbus/xbus or at the least a channel input into the esc to apply feedforward. but that would probably require a major redesign but it would be the best of both worlds. Internal governor with external feedforward...

Quote from my Kosmik sticky.

2. Ri Comp. There is no simple answer to this and I will try to explain in terms that will help and not go in to much detail as it will give away information about how our governor works as it is information that is deep in our programming. What it does it match the Kosmiks output to match that of the motor Ri (internal resistance). It gives the Kosmik some forward feed or a better description would be to make the governor function more proactive than reactive. The Kosmik actually knows what is going on by seeing the information live from the logging such as battery current, motor power, throttle position etc so it not only sees the throttle position it can determine how hard the model is being pushed but it can not take into account items such as the models weight and the drag on the model.

[mkovalcson]

Originally Posted by jamin_00

Quote from my Kosmik sticky.

2. Ri Comp. There is no simple answer to this and I will try to explain in terms that will help and not go in to much detail as it will give away information about how our governor works as it is information that is deep in our programming. What it does it match the Kosmiks output to match that of the motor Ri (internal resistance). It gives the Kosmik some forward feed or a better description would be to make the governor function more proactive than reactive. The Kosmik actually knows what is going on by seeing the information live from the logging such as battery current, motor power, throttle position etc so it not only sees the throttle position it can determine how hard the model is being pushed but it can not take into account items such as the models weight and the drag on the model.

What I've found is that people who prefer an external governor over Kontroniks built in governor don't actually care if the headspeed is perfectly smooth.

What they are looking for is to goose the motor when they give it hard collective input which they like the feel of even though it results in overrevving the motor a bit. That requires knowing what the pilot is doing, but is not being done in the name of keeping a constant headspeed.

Personally I like the simplicity of leaving it up to the Kontronik governor. I get a perfect spin up and solid headspeeds with no tweaking required. The secret sauce is very good!

[-G's]

Are the new Jive Pro's going to be the same physical size as the current line? Is another 100 coming as well or just 80 and 120?

[DannyvG]

Originally Posted by jamin_00

Quote from my Kosmik sticky.

2. It gives the Kosmik some forward feed or a better description would be to make the governor function more proactive than reactive. The Kosmik actually knows what is going on by seeing the information live from the logging such as battery current, motor power, throttle position etc so it not only sees the throttle position it can determine how hard the model is being pushed but it can not take into account items such as the models weight and the drag on the model.

sorry but that is all still feedback control. It might be pretty advanced feedback control but nonetheless still feedback control. Which is always limited by the fact that it is always late. Look for the Bode sensitivity integral aka waterbed effect, improvement in one area will lead to deterioration in another. Improvement by feedback is thus always limited by a trade-off while feedforward isnt.

Obviously it isnt comparative but in high tech motion systems 99% of the generated forces are determined by feedforward. The feedback is there mostly for disturbance rejection and to cope with changes in plant properties. But it is clear that feedforward is very important in motion systems.
So I really do think that a feedback based governor can always benefit from feedforward. And most of you guys seem to compare it to the vbar governor which isnt all that good to begin with. The vbar seems to have a lot of lag in the feedback loop. The brain governor is a lot better in that respect but it lacks a bit in other places. So the best of both worlds still is feedforward to the esc's governor.

And as mkovalscon mentioned people have different expectations from their governor. For me I would want it to be a minimum rpm kind of thing, overspeeding (to some extent) isnt a problem but bogging shouldnt happen.

[dl7uae]

That's really amazing.. All have faith, but why not thinking about?

Thinking.., thinking about the involved timing.

How fast can a control loop (rpm) react without bad side effects on tail - and at least with FBL on the other two axis too?

Not very fast (->counter-torque). Slow rising pwm in case rpm drops, fast dropping pwm in case of overspeed.
That's btw the "secret" of Kontronik's speed control algorithm: It is an asymmetrical one, different PI for both modes of control.

And now the 2nd question: What amount of time in advance do we have for the legendary feed forward?

Marginal compared to the time we have to take for the resulting action, rising pwm.

There can be not much positive effect - but there can be also negative one. The landing point for setup of a control loop (yes, also the Vbar Gov is a controller from it's basic nature) with feed forward is very small because at last you're feeding an additional deviation into the control loop.

So many people saying: That kind of speed control is the best ever. Do they know, did they measure, or have they faith?
I thought about (no art, it's my profession) and I experimented, measured (logged) on a motor test device.
And so you hear me saying for the umpteenth times: That all has a fairytale character.

No question! It is good for use on ESCs with not well-functioning speed control.

----
Is this the last time I write about this topic? I'm afraid not.
Sorry, I'm doing this. Nobody likes it when his faith is called into question.
No offense. I do not want to occur as smart alec. I just had to "suffer" when I read this repeated discussion.

[DannyvG]

Originally Posted by dl7uae

So many people saying: That kind of speed control is the best ever. Do they know, did they measure, or have they faith?
I thought about (no art, it's my profession) and I experimented, measured (logged) on a motor test device.
And so you hear me saying for the umpteenth times: That all has a fairytale character.

Are your test results somewhere to be found on the internet? Or some more on this subject in another topic? Cant find much relevant with the search function.

My own experience, and logging, is in favor of the brain governor over te vbar and jive governor. so is it faith? or preference? and what is the goal?
apparantly you say here

Originally Posted by dl7uae

Well, the 66% throttle in log #1 is already a bit high.

RPM drops: No joke: this is intentional. Yes.

Why? The control algorithm is asymmetric. Rapidly decrease PWM with increasing speed, slowly increase PWM with decreasing RPM. Again: Why that? To keep the anti-torque low. Thus here a more constant speed is NOT a priority.

It is important and essential for a good control algorithm to proceed exactly this way.
(And that's also the reason why I say: The feed forward of the Vbar gov is ineffective because we cannot bring it to effect for exactly that reason and purpose. And I know and see it from test logs that Uli has changed the governor to smoothly handle rising throttle (-->PWM).)

Tom

rpm drop is accepted in favor of improved tail performance?
But how about being more aggressive on the pwm increase and improve tail performance with feedforward to the tail? or accept decreased tail performance for improved governor performance?

Originally Posted by dl7uae

And now the 2nd question: What amount of time in advance do we have for the legendary feed forward?

Marginal compared to the time we have to take for the resulting action, rising pwm.

what kind of numbers are we talking about here? how much time is there between collective pitch input and rpm drop? and how much rpm drop and time is there with the jive or kosmik before throttle out and subsequently actual pwm is increased?
the sooner you start with pwm increase after stick input the less rpm drop there would be, which in my book would be a good thing. but apparently not everybody agrees.

[mkovalcson]

Originally Posted by DannyvG

the sooner you start with pwm increase after stick input the less rpm drop there would be, which in my book would be a good thing. but apparently not everybody agrees.

The Kontronik ESC has nearly instantaneous feedback from the motor to know exactly how it is going and can react accordingly.

The FBL controller gets a delayed speed reading from a sensor that is history saying where the motor was. Meanwhile the FBL controller receives the collective input from the reciever which is effectively the future. Now it needs to reconcile what PWM the motor will need based on where the motor was and where it will be once the servos respond to the collective input.

The FBL controller has to calculate a number of things extremely well just to be remotely competitive with what Kontronik can do nearly instantaneously.

There are a lot of downsides to external governed operation as well. increased complexity with more parts to fail, and more settings that need to be right for it to work well.

I greatly prefer just setting my Flight Mode throttle values to get the headspeed I want and be done with it.

[Seasick78]

Originally Posted by mkovalcson

I greatly prefer just setting my Flight Mode throttle values to get the headspeed I want and be done with it.

+1

[DannyvG]

Originally Posted by mkovalcson

The Kontronik ESC has nearly instantaneous feedback from the motor to know exactly how it is going and can react accordingly.

but rpm has to drop before a feedback controller will increase control action. while feedforward can increase control action before the rpm drops.

Originally Posted by mkovalcson

The FBL controller gets a delayed speed reading from a sensor that is history saying where the motor was. Meanwhile the FBL controller receives the collective input from the reciever which is effectively the future. Now it needs to reconcile what PWM the motor will need based on where the motor was and where it will be once the servos respond to the collective input.

Feedforward can be very simple but already very effective. Just add throttle scaled linearly with collective pitch input
Also I would be surprised if the yge rpm output has more delay then the internally used signal and the clock speed of an fbl system is plenty fast to give negligible delay. Only problem is when the rpm signal is very noisy or the interpretation of the signal is poor, thats where the esc is a lot better.

But I am not saying kontronik should go towards an external governor mode, they should accept feedforward input.
Just have the vbar or brain put out a signal that is comprised of steering inputs so the esc really has instant knowledge of the load getting on the motor before the rpm actually drops. This would be a lot better then feedback only or the external governors.
But untill then I will stick with my perfectly working easy to setup yge with brain governor

[dl7uae]

Sorry, Danny, my response will be delayed. I'm busy right now.

[DannyvG]

no problem, you can also pm me anytime, no pressure. and I will leave this thread about the new kontronik products. was just wondering why they arent going a step further in what seems logical to me.

[Seasick78]

Looking forward to your next contribution to this thread, Tom.

[jstalnaker70]

helidirect has the 120pro listed
but all sold out
who else has them?

[Sonixs]

Originally Posted by jstalnaker70

helidirect has the 120pro listed
but all sold out
who else has them?

Interesting...
Kontronik in Germany said that they'd only be available in June 2014.


Sent from my iPad using Tapatalk

[Wh1teAfr1can]

I'm sure they are just in helidirects system but out of stock means no stock yet. Prob just an easy way of keeping up with new products early and showing you will carry them.

As above the release date is scheduled for 2nd quarter of 2014

[Vinger]

Local shop also shows them on their website, no stock and for FREE!

http://www.goblinhobbies.co.za/s-eed...kontronik.html

[GimpyGolden]

Originally Posted by Vinger

Local shop also shows them on their website, no stock and for FREE!

http://www.goblinhobbies.co.za/s-eed...kontronik.html

Alright Vinger. I'll take two of each, can't beat that price even if with shipping from South Africa.

[GimpyGolden]

Seriously though glad they aren't charging an arm and leg extra for the next evo of the Jive.

Guessing they will discontinue the Power and HeliJive lines then if this is an all in one?

[silas3d]

Other than re-using the Jive form factor these seem more like baby-Kosmiks to me based on the feature set.

In fact, unless you can make a compelling case for needed a 160A controller I see no reason to buy a Kosmik once these come out as the higher current capacity would be the only remaining major discriminator.

That being said I'm really happy with my helijives and likely won't try one of these out unless I get a super deal on it.

[Wh1teAfr1can]

Originally Posted by silas3d

Other than re-using the Jive form factor these seem more like baby-Kosmiks to me based on the feature set.

In fact, unless you can make a compelling case for needed a 160A controller I see no reason to buy a Kosmik once these come out as the higher current capacity would be the only remaining major discriminator.

That being said I'm really happy with my helijives and likely won't try one of these out unless I get a super deal on it.

That is the point the same way the Koby is based on the same newer architecture. They are meant to update the jive line so that for smaller lighter weight machines you can have the same feature set as the kosmik minus some of the built in features and the number of accessory ports.