Force Feedback Yoke project

I’m curious. The HID part is clear, how did you implement the communication from the simulator to the board?
It’s really nice. I guess you have an encoder on the motor and you use it like a servo?

Can a SIMPLE purpose built software layer that reads altitude changes, yaw, pitch and roll specific to aviation (from simConnect) and negotiate then send vibrate variable data/signals to the motors?

Flaps, Gear also separate variables. G force changes a simple indicator also.

Realistically this needs to be C++ and low millisecond latency to “feel right”.

Getting a servo to move flap position is a magnitude simpler than a “real time” force feedback…

I feel that OpenFF layered on MSFS will not be a good match in simulating flight forces - due to latency between event and simconnect and OpenFF

THIS IS AN AWESOME THREAD!

Not so hard at all. A typical brushless motor is the 3 phase motor. By setting the required voltage to these 3 windings, the motor shaft is set to a desired electrical phase. If this electrical phase is then moved by 90 or -90 degrees without moving the shaft position, then the maximum torque is applied. If the required torque is lower than maximum, then a lower phase shift (between 0 and 90 degrees) must be applied or a lower voltage amplitude. The torque can be fully controlled as long as the motor shaft position is always known. This is why a kind of position sensor must be used in the motor.

That’s right. The encoder tells me where the motor shaft is positioned. If I set the voltage to 3 motor windings that way, that the motor tries to move a bit, the torque is applied. The maximum torque is achieved when the current electrical phase shift is -90 or 90 degrees from the current motor position. The torque is controlled in a loop every 10 ms.
The communication is handled by an additional program written in C++, which communicates with the simulator by SimConnect functions and with the board by USB HID interface. In the example shown in my movies, two simulator variables are being sent to the board: number of flaps positions (it may vary between airplanes) and current flaps index. From the board the current lever position is being sent to the simulator. When it is changed by a user, a new flaps index is set in the simulator.

Yes, but for a specific reason. My haptic lever can work in the “spring” mode, like a typical joystick with a fixed spring. The difference is that my “center position” can be changed and set to any position in real time. This way this joystick reference position can be controlled by a set of force feedback parameters from the simulator. And this is where the trickiest part begins. MSFS doesn’t provide ready to use force feedback variables. Instead of that, some other parameters, like relative indicated airspeed, G-force applied to various aircraft axes, force applied to gear etc. must be used for calculations of force feedback forces.

2 Likes

Exactly. Also because, if I understood correctly, the system where they sense the backEMF cannot be used if the motor is stalled, like will happen in an application like this one.
The issue is that, while on a DC motor the torque (current) control can be done in hardware, a system like this I would say that requires a microcontroller, even just to monitor the position sensor and apply the correct set of sines to the phases.

I think I’ll go and dig into my box with motors, maybe I have some old brushless that I can use to try. Or I’ll get a small one and start playing with it.

All clear, thanks. This SimConnect has come out already too many times in this thread to keep ignoring it, I definitely need to start looking into it.

Indeed, I’m using XPForce that does precisely that -without the need of SimConnect.

Now, this is pure pleasure for an engineer’s eyes :laughing:

Here I have in blue to PWM value (torque) for the inertia effect, in orange the speed calculated and in gray the position.
When the setting of the inertia is too high it starts vibrating, but when it’s low it’s not working too well either. I’m still missing the part where it opposes to the stop of the axis.
I think the problem is that the speed has values too low and it gets very sensitive to noise.
I will try to use a longer time to calculate it…

1 Like

Now we are talking. Damping and inertia are working well now.
I had to adjust the delta-t for the calculation of the speed to get more stable and higher values, and that almost fixed the acceleration too. I had also to change a few coefficients I use internally to limit the values.
I still get vibrations if I set the torque too high, but that is due to the mechanics of the slider, that starts jumping back and forth because the belt jumps. Nothing to do on that until I’ll get real mechanics.

Now… let me try to see what I get… with MSFS :face_with_monocle:

Ah, this is nice. I made a very short flight just to see what I was getting.
These plots are for the X axis (roll):


You can see that there are no periodic forces set, there is friction (that feels the noise in the reading of the position, that’s why it’s a sort of thick line), then mainly spring, some constant force at the beginning, and oddly also at the end looking like inertia when I was being silly with the plane.

Even more interesting the Y axis (pitch):

Here there are two use of the sine during take off (beginning) and when I tried to move the flaps (near the end). Every other periodical effect is quiet.
On the other forces, the usual friction, and again constant force.

In the lower plots, for both axis, you can see the position of the axis (orange) and the total force applied (positive here, I don’t get the polarity for now).
I see, for example, a possible error -but I’m not sure. All forces are calculated individually and the overlapped, so two opposite forces will erase themselves. In this part of the flight

you can see that I get a negative spring effect and a positive constant force effect.
In this case, the constant force is higher than the spring, and would win over it. I don’t know if it is intended, but I will have a second look at the signs in the cose. I have used the same formula for the calculation of all directions, but… who knows.

Well, I really like this. I think it’s time to dedicate some time to the motor controller then…

Havent been here for a few days and things seem really progressing! Cool!

I have been also looking at the electronics and might opt for the TMC4671 as a motor controller. So I would not have to mess with the commutation. I will try to keep it close to the Open FFB Project but replace some ICs with some more generic parts. From what I saw they used some exotic parts.

In the meantime I started working on the mechanics. I am trying to keep the design compact and as easy to manufacture as reasonable while relying on standard and easy to source parts. Most of the stuff will be 3D printed. Not done yet but this would be the carriage for the Aileron. Its using a Standard 86mm BLDC Motor with encoder. The current implementation would deliver up to 2Nm. Using the pulley with a 1:4 Ratio, this will be enough. I saw some off the shelf racing wheels that are also using around 5Nm of force which seems to be enough. As I dont plan to hit any potholes while taxying nor in the air, this should be enough. However, changing the motor is easy as the strength is mainly dictated by the length of it. All you would need to do is adapt the connector inbetween. I do have access to a cirrus and a PA28, so my plan is to get up and measure some force on the flight controls to get some real numbers instead of doing the guessing game.

Basic design is one 20mm tube where you can route your Yoke cables through for the Aileron. Behind the big pulley there is a groove ball bearing (secured by a circling clip) that takes the axial, as well as the radial loads. In the front part there is a simple (igus) sleeve bearing. This sledge is then gliding onto two 12mm Precision Rails for the elevator. The tube and the rails are on one axis so there is no pitch moment induced. The Belt (not shown) can be tensioned by tilting the motor thorugh the elongated holes.

Next will be the implementation of the Elevator Axis. Not sure how to connect it to the motor yet.
The red connector is (missing bolts and) will be the same material. Just used a different color for better understanding.

Just a work in progress. :slight_smile:


2 Likes

Now, that is some serious 3D. It admit that it took me a while to understand if it was a 3D or a photo :smiley: the plastic parts look real, but I decided to go for the 3D due to the motor look and the lack of teeth from the gears… I hope I’m right, I still have doubts :smiley:
Mine in CATIA are quite awful, I have never learned how to make them look nice…

Indeed, more progress that I expected myself. I guess once you get the USB code right, the implementation of the effects is rather straightforward. And the PIC I’m using, at the moment, didn’t require any optimization at all. It’s so fast that even sending out data on the serial port had no impact on the performances.

image

That’s a rather complex controller… but I guess it’s what you need for a serious control of these motors.
QFN76 … :persevere: I hate that package, they are impossible to solder by hand. I had to mount some QFN mosfet and ICs and most of the heat was due to my swearing…

One thing that I would like to improve from the usual design that I have seen around is the fact that, when you push/pull the yoke, you “carry around” also the motor for the roll movement, which adds mass and inertia.
I wonder if there is any benefit in trying to change the design to leave the two motor fixed on the frame. I have an idea, let me see how I can explain it…
There could be two … ok, no. There is nothing better than a sketch on a piece of paper:

If you use a mechanism like this, the outer part (which is the one where the yoke is connected) can be pulled in and out and turned by turning the inner part. I’m not sure if it makes any sense.

Can you let me know, pleeeeease? :pleading_face:

Any suggestion about where to buy these motors in UK? Thanks to brexit purchases from EU have become impossible or extremely expensive…

—edit: just found two 86BLS71 on ebay, for £75 each… not as powerful as the one you mentioned, but I couldn’t find anything else without shipping from abroad or paying a fortune. Let’s see what I can get of of them.
I’m thinking to give it a try with a microcontroller based driver before going to something more complex.

or – $5

Haha, indeed. This would justify a new hotair soldering gun :grimacing: . One could also create a via under the termalpad to reach through with the soldering tip, but this wouldnt be semioptimal.

Haha. Yets its a render. Okay, let me fix that, just need to put some details to the pulley…

No, these results are mine! Haha, no of course I will share them. I first have to think how to test it as I would have to measure the deflection and also the force needed. Then preferably plot/note them simultanious… or am I think to complicated? :thinking:

Interesting. Definetely something to think about. The implementation would also not be to complicated as it is very similar and only needs one additional fixture for the Radial Forces.
However, I dont think the ~3kg would make a different for our scenario as the forces in Flight Simulators do not have very high accelerations or short peaks but its definetly worth to test!

Yes, the ones I mentioned are directly coming from china. Shipping to germany would be around 60€, almost as much as the motor itself and would also take ages.
I think I will go either with a 86BLF03 (66€) or 86BLF04 (88€) shipping directly from germany. As it looks they are also just releabeled china stuff. The seller actually seems to be here in my town but looking at the contact section on their website I only found a chinese landline number… totally legit.

But these motors are actually rated for 1,05Nm (1,4Nm for the bigger one) but also at 3000rpm! The maxiumum torque is (which I assume) reached at 0 rpm and mainly the use case for us. Here they deliver up to 3.2 CNm (China Newton Meter) for the smaller and 4.2CNm for the F04.

Just had an idea for the motor control.
With the brushless, you need to know the position to know how to power the phases.
But were we know what the position is, because we have the potentiometers on the axis.
So imagine that we have a 1:1 link between motor and potentiometer, for example on the roll axis, for a total of 360 degrees: it is possible to build a table linking axis reading with motor phases.
If the ratio is 1:10, there will just be a lower resolution (10 motor cycles on the n-bits of the reading, but still, very good), but the principle still works.
In this way, the control would work like some sort of servo motor, and there would be no banging issue either: once the reading reached the end of the scale, 0 or 2^n bits, the phases won’t move again (and neither the motor axis, since they are linked to the potentiometer and there would be a hard mechanical stop in any case) but the torque would still be there locking it in place.
What do you think?

I recommend Weller, I have the WR3M and WR2000 and they are great. I had some chinese cheap stuff years ago and it wasn’t worth of the qualification of a hair drier. Total piece of junk.

I think what is needed is just the maximum? The value in each situation will then be given by the simulator. Probably just a dinamometer to see the force that you need to apply could be sufficient?

It could be that I am overthinking it, yes. Still, 3kg would be a significant part of the mass to move.
But whatever solution I’ll chose, building it will be difficult for me, I have a small milling machine that I was going to transform into a CNC but I never had the chance to finish it, in any case it would be way too small for this work. I will need to find someone to make the metal parts for me.

The “BLF” you mention seem to be different from the “BLS”, with more torque… bah, whatever. I found those two, I’ll have a look at what they do. They might be sufficient.

Indeed, I was going to say the same. I saw some plot of the torque/speed/current and I think in stall condition we might have some pleasant surprise.

Yes, this is how it should be implemented. The actual implementation may be a bit more complex though, since a typical BLDC motor has got multiple electrical revolutions in a single physical revolution (I have got some motors with 4, 7 ,8 ,9 and 12 electrical revolutions in one physical revolution). But this just an implementation challenge.

once the reading reached the end of the scale, 0 or 2^n bits, the phases won’t move again (and neither the motor axis, since they are linked to the potentiometer and there would be a hard mechanical stop in any case) but the torque would still be there locking it in place

One should be careful here, since a BLDC motor, even with a forced electrical phase, still can be moved by an external force. So the torque control procedure must be aware of this effect, monitoring the current shaft position and adjusting the torque accordingly.

Exactly. So basically the control would be given by the potentiometer reading for the phase combination (even hardcoded once the system is characterized) and the current for the torque.

For those who are building the mechanics with a 3D printer, have you ever consider/tried this technique?

I was reading some test report like this one

and results look quite good. I’m printing a few test parts to check the resistance, I’m not a big fan of plastic, but until I can’t get anything better…