Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.
You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks!
05/03/2024 - This forum is read-only
The community support for MobiFlight has moved exclusively over to our Discord server. Register for free and enjoy more interactive functions like image and video upload, voice chat. More than 7,000 registered users around the world make it a great experience!
A HUGE Thank You to everyone who participated in the forum, especially obviously to Pizman and Stephan who did an outstanding job over so many years providing an incredible service to the MobiFlight community.
The forum is still providing a lot of good content, hence we keep this information accessible.
As i'm still not retired (sorry, Volker) and my job as a consultant is kinda stressy in this days, this would be the only time slot i could make before pizman goes into vacation (?).
Sh....i must admin that my first tests are a total failure.
Not with the logic or the electronics, but with the mechanic.
With the many gears i was going to use, the force was to much and i grilled my tiny stepper tonite.
In my plans i do not have much space, so i'm not sure whether i will change my design (3D printed) for another, stronger (and bigger) stepper or whether i roll back a little and just build a moving trim wheel, just to have something "moving"....not totally realistic .... but coooool
My favorite plane is a Airbus 321. Since Airbus invented "Fly by wire" the pilot normally never touches the trim wheel. If he wants to change the elevator trimming, he does it over the FMC, not the wheel. Only when the trim computer AND the FMC is dead (ouch) then he could move the wheel. (But if this happens he has some other more serious problems, doesn't he?)
Well, i assume this case won't ever happen in my setting.
OK, my stepper is not dead, there must be some strange things going on when running any tests plain under Arduino.
Connected with MF the stepper does what it should do, when connected to Offset 0BC4, Elevator Trim.
But additionally i know now, why pizman says, a stepper won't work here for a trim wheel.
1) The supported 28BYJ is far to slow to follow the trim wheel
2) There is no way to say MF "turn the stepper until Value XYZ (coming e.g. from a poti) is reached". MF only says: Hey, Stepper, turn around for X steps. Period.
If this would have been said prior i would have saved some time. But on the other hand, i learned a lot.
Therefore i will change my whole design - especially the 3D printed parts - and will go with a DC-Motor.
The solution would be, if there would be a possibility to create a "virtual servo", consisting in reality of a motor (DC or stepper) in combination with a poit.
As a servo is among some electronics nothing different, MF could be able to treat this virtual thing as a servo.
The user is responsible to be asure that the motor always drives the poti and during creation he only says on which pins is the motor and on which pins the poti and what are the border values (most left / right) and what should be the zero-position.
Then it should be possible to have a controlled (i know always where you are) condition for motors as well.
Very interesting discussion here, I should have ealier a look here in the forum, last visit was beginning Januar.
I planed also for a motorized trim wheel since a couple of weeks and could realize a first prototype last days.Not as nice as Volkers one and still to make some changes.
From the beginning I planed using a stepper motor to avoid having a clutch. Instead the enable signal from the driver board is used to dis-/enable the motor. Furthermore the maximum current and therefore the maximum torque can be adjusted on the driver board, so it is still possible to turn the motor even it is enabled.
The Trimwheel is directly connected to the motor shaft, additionally a 1:1 gear connects the motor shaft and a poti. BUT! to get a closed loop control the firmware must be modified, as the stepper commands from the UI are absolute steps and not relative ones as required (PotiPosition - RequiredPosition = DeltaSteps!).
The number of movements of the Trimwheel can easily increased by changing the gear ratio, the Trimwheel stays on the motor shaft and after the gear comes the poti. Or like Volker did using directly a 1:10 poti.
For now the hardware is not completly finished (right side of the casing is missing), the modified firmware is running (including moving the trimwheel to the mid position on startup) and the first flight was done yesterday evening (but just checking if the trimwheel moves in AP mode). The next test will follow hopefully on the weekend.
The hard task is what Pizman mentioned below how to detect a manual movement and how to react on this. I guess this will something time related (position not reached within x seconds) and setting on output so that the UI can react on it.
The hard task is what Pizman mentioned below how to detect a manual movement and how to react on this. I guess this will something time related (position not reached within x seconds) and setting on output so that the UI can react on it.
Meanwhile we have a solution for this.... But its also based on a "Clutch".
I know you guys not like this idea.... I just can say its the most logical in my eyes and is used by all "professional" systems i spot till now.
About the "Intervention" Problem....
We solve this on a users prototyp by two simple Momentary Push buttons within the Shaft Mechanik of the Throttle Handle.
The Handle is connected by the Clutch with the Motor.... If Motor is turning the low weight and the "strong" connection with the clutch will turn the Handle directly 1:1
Below and above of the Throttle Lever shaft we mount each a Push Button. If we move the Throttle by Hand against the Clutch, then we press one of these Buttons by push/pull the Handle the first 2-3 mm moveing range against this button.
And THIS Button Press now is detect and Enable within MF the Poti for Inputs !
If Buttons are not pressed then MF didsable the Poti Input Config!
In easy words.... The Motor turn the hub of the whole mechanic..... The Handle turn also the Hub but press same time one of the two Buttons.
So we have our needed Indication if Input is done by Pilot or not.
As soon as the last ordered part arrives i can make my final tests and will share the result.
But for now in theory, on how Volkers idea is designed, i only made some minor changes to it:
- there is geared motor (~70 RPM) connected to the electronic stolen from a 20kg servo (-> no stepper )
- there is a 10-turn-poti (lets call it A) which is always connected to the motor and also connected to the mentioned electronics
-> we made a new servo being able to turn 10 times whch is enough for the trim wheel (in an Airbus the wheel makes approx 8 turnes max)
- over the 3D-printed-gear the trim wheel is moved by this "servo" and also another 10-turn-poti (lets call it B )
Autopilot on:
- MF transforms the elevator trim value to a value our "servo" understands
-> the wheel is moving
Autopilot off:
- a small 9g-Servo moves a swivel to the right, which mechanically disconnects the motor from the trim wheel
- you can move the trim wheel manually and poti B sends values to MF
- MF transforms this value and send it to the simulator
- at the same time this value will be send back to our "servo", also it has nothing to move but the poti A right now
-> both potis are always synced
Autobilot on again:
- same as already mentioned some lines up
Again, this idea comes from Volker, i only made some small changes to fit my needs.
My very first tests were also with a stepper but i failed dramatically. Therefore: the better is the dead of the good and i adopted Volkers gear-solution
I just ordered the 20kg servo to steal the electronics and as soon as it arrived (and i'm back home from a long weekend out) i will finalize my test environment and will give feedback. Approx Monday night. All parts to print are ready and waiting to be moved
And THIS Button Press now is detect and Enable within MF the Poti for Inputs !
If Buttons are not pressed then MF didsable the Poti Input Config!
If the AP is enabled, you send the position from the poti to the Sim. Will also the AP be disabled?
If not, how does the Sim react? The AP tries to set a position, but frrom the wheel comes another position?
Does the Sim not get confused?
The AP in a real Aircraft ( and also in the higher professional Sim Aircrafts like PMDG) allow a "override" .
In Real the position of the Throttle is ALWAYS the indication of the Thrust.
Means....
The AP not set the Thrust ( internal) e.g. to 80% and then move a Motor to also set the Lever to 80% position..... In real the motor move the Throttle lever.... And this INPUT from the Lever finally controll the Thrust ....
See the Motor like a hypothetical person who move the throttle by hand when the AP tell him to do.
Summary.... A Input on the throttle ( whatever by humand hands or by the motor) always act as a Command in real.
In Sim we get a problem.... Cause our Motor technical just show the position of the virtual Joystick! .... So the Thrust of the Sim Aircraft can be higher or lower as our current Real Throttle Position ( E.g. 1 second after Sim make a big move by the AT).
We have no access to to AP System itself that tell us in what position it like to move the Throttle.... So we are a little delayed.... Cause we can "see" the new Position only AFTER it still have moved in the Sim.
And THATS what get problematic for us.....
As i explane above.... Lets say Sim is on 50% and Throttle also on 50% .
If AP set to 60% in Sim our Throttle is still at 50% .... It see Sim is in 60% and start to turn the motor.... BUT After our real Throttle move and reach e.g. 52% ( on its way to 60%) this MOVEMENT would also occure in a INPUT.... Cause Sim is at 60.... Throttle now is at 52 and would tell the Sim " Please set to 52 now"
Summmary again.... We need to "disable" the Inputs while Motor is moving the Throttle temporary..... Simply cause we have to handle this Delay. In Real we would not have the problem cause the Throttle always represent the current thrust.
About your final question.....
If not, how does the Sim react? The AP tries to set a position, but frrom the wheel comes another position?
Does the Sim not get confused?
No..: thats the "Manual Override" that also exist in real.....
Lets say your AT is ON.... And lets say Throttle is in 90% Cruise flight.
The Pilot can at avery time take his hands on the trottle and move it.... Lets say he put it to 50%
If he put his hands away the Motor will turn the Throttle back to 90%
If he "hold" the throttle then the motor detect a "back pressure".... I think it still try to move the throttle but it can not fight against the Pilots hand.
Finally there exist Aircraft Systems.... For example the "Rejacted Takeoff" or the "Idle Hold Descent in "Level Change" Mode.
Here the Captain for example pull the trhottle by hand to IDLE and hold it there for a second.... Then the SPD Mode in PFD change into "HOLD" Means the AT sleep untill the aircraft reach the current selected Target Altitude . In this situation technical AP and AT are both still ON.... But it "sleep" in case Pilot move the throttle.
In Aborded Takeoff the same.... Whatever Sim AT is on.... When you pull down the Throttle to IDLE Posm the Aircraft start the Stopping sequence ( Speedbrakes Up, Full Autobrake RTO) .
Last Note: Also here the "Clutch" is again the key.... If we hold the throttle against the motor, then the motor will turn but it simply do nothing in case of the clutch !
For now my trim wheel centers on start up and can be used like a normal one if AP is OFF. The poti input is activated. Once AP is ON the trim wheel follows the position coming from the AP (OK, up to here it is the easy part) and the poti input is deactivated But I can also move the trim wheel in this condition.
My next step is to think about how to detect a manual movement while AP is ON (what you have done with the 2 additinal switches) and what to do with this information (e.g switching holding altitude OFF).
I guess it will be something like: once I have reached the setpoint and if then the actual value differs over some time too much from the setpoint, then set this additinal output.
@ Elral.
Thats exactly the Problem of the Stepper.....
You Solve Part 1 ( Inputs while AT OFF)
You solve Part 2 ( Outputs while AT ON)
You also solve Part 3 ( Blocking Inputs aslong AT is ON)
BUT
You miss two things.
1. You can now not make a Manual Input against the AP ( Not sure if this is needed basically.... Why should a Pilot Trim a Aircraft if AP/AT is still hold Speed/Alt )
2. If you turn the Wheel your "Stepper" will not understand this..... Cause for it it still stands on the Position where it was before you move it.
Solution:
I still not understand hwo you guys do this.... With a DC Motor we could simply compare the Virtual Position and the Real Position.... So Our two Systems are always Sync.
But i not know how to do this with a Stepper!.
And finally as i said in the past..... Maybe best Compromise is to use the Trim Buttons on Yoke.
You have a INPUT by the wheel when AP is OFF..... You have a OUTPUT on the Wheel aslong AP is ON.
The only thing.... If you like to trim WHILE AP is ON you can NOT use the wheel.... You use simply the Buttons on Yoke !
Not perfect.... But pretty sure working.
I will say most of pilots who have a Trim Button on Yoke will never again touch there wheel in AP Mode !
@ Elral.
Thats exactly the Problem of the Stepper.....
You Solve Part 1 ( Inputs while AT OFF)
You solve Part 2 ( Outputs while AT ON)
You also solve Part 3 ( Blocking Inputs aslong AT is ON)
BUT
You miss two things.
1. You can now not make a Manual Input against the AP ( Not sure if this is needed basically.... Why should a Pilot Trim a Aircraft if AP/AT is still hold Speed/Alt )
2. If you turn the Wheel your "Stepper" will not understand this..... Cause for it it still stands on the Position where it was before you move it.
!
sorry that I have to contradict, that is not a problem of a Stepper.
to 1. I can move against the AP, the max. torque from the stepper is limted by adjusting the max. current on the stepper driver. But as you also sayed I am still not sure if this is done in real aircrafts. I recall that for the AT you gave already an example above.
to 2. It is not necessary that the stepper nows it's position. It's the same as using a DC motor. The pot is on the wheel, both are driven by the stepper. I got the setpoint from the Sim and have the actual position from the pot. So I can calculate the required number of steps to move the trim into the required position while using acceleration, max. speed, ...
Maybe we should continue on Discord where I can show some pictures...
Hi,
maybe Pizman's understanding of a stepper relys to the way, steppers in Mobiflight work. Considering this, he is absolutely right.
In the industry, steppers are often used in other variants. The stepper controller has only three inputs: Enable, Step and Direction. Similar to Mobiflight, one must also take care of the count of steps with the computer (Arduino or whatever).
In machines and aircraft, servos also have a feedback in form of a position encoder. This is called closed loop contrary to the Mobiflight open loop approach.
Here, Mobiflight always needs to know where the stepper is positioned. Hence Mobiflight needs to be always in control of the stepper. Manually overriding the stepper position would result in Mobiflight losing the actual position of the device.
My approach would be to sensor the lever input force (either via force sensor or some switch) and let Mobiflight do the work of repositioning the lever. I tested this with a strong servo (20KG) but it was very bouncy because with a given servo electronic, I cannot influence the PID values.
I would have tried it with a stepper, but the 28BYJ-48 Stepper are to weak and Mobiflight does not provide means to connect a NEMA 17 or 23 stepper.
I'm in 
Supporter
