Force Feedback Yoke project

I agree, that is the key. A servo motor is what is needed. But… “servo” motor just indicates a motor that has some sort of encoder connected, then it could be stepper, brushless, brushed…
That is what I’m trying to do. But synchronizing the position of the shaft with the three phases in a decently small code is far from trivial…

No! You can do it almost linearly, in an analog way and feeling. The only limitation is the motor/mechanics precision and calculations/PWM resolution. Anyway, a motor can be set to a certain position with a fraction of degree resolution.
By using the motor shaft position feedback (rotation encoder, not simple HAL sensors!), a motor is turned into a servo indeed. With a simple driver and smart software, the torque can be precisely controlled.

That’s true. This is just a servo. The synchronization is not so difficult, but not trivial either. I can explain in more details later.

Thanks.
Following the idea of the technical note I linked earlier (but not entirely because the device I’m using doesn’t have DMA), what I did yesterday night was to create a routine to load the PWM value from the sine table at each change of the hall sensor configuration to the starting point for that “quadrant”, depending on the direction of the rotation.
Then on the ADC interrupt, I move to the PWM value corresponding to the position of the potentiometer for that quadrant.
If I had enough memory I could make one single table with a 1:1 mapping, but I can’t, unless I lower the resolution. So I can map one electrical cycle only and repeat it.
But it doesn’t work, I need to check the PWM output to see if I’m doing some mistake on the configuration, the values from the PWM register look reasonable but the output seems to be missing on some port.
I’ll try to have a look later today.

The hall sensors are not very useful in this application. They only give information about certain points of the rotating shaft. What you need is information about the shaft position at any moment. The yoke may stay steady or move only slightly, not triggering hall sensors, yet still, it should function properly.
You can use a potentiometer as the position sensor, but it is not very precise (mechanical play and non linearity). Better solution is to use magnetic rotation encoder or optical absolute encoder. Knowing the current shaft position it is possible to set a desired electrical phase for holding the shaft steady or generate a desired torque as the the force feedback response.

Yes, I have noticed that. This is why in my idea I’m using the hall sensor to re-synch the sine table with the correct point each time the hall sensor output changes.
But I agree, an encoder should be the best solution.
Problem: how do I apply an encoder on these motors?
They don’t have a read shaft where I can mount it, so it should go on the front, but I can’t find anything.
I’m looking for brushless motors with encoders but what I find is either huge or ridiculously expensive. Any idea?

Many motors have got their shafts accessible from both sides. If not, there’s a problem indeed.
When a shaft is accessible, all one needs is to glue a small cylindrical magnet with diagonal polarization. The encoder chip is typically mounted in distance 0.5 … 3 mm from the magnet. The lack of any mechanical coupling is a big advantage here (the motor can freely rotate if needed).

I have found this device

it seems to be the only thing at a decent price that I can find on ebay. ■■■■ brexit and its customs… There are servo motors from EU. Not as many as from US, but still, more and cheaper than from UK.
I might get one of these to try them. But my shaft is 1/2", oh but these are only up to 8mm :sob:
I need to find something else then.

I’m using these encoders:

The output can be digital (SPI), PWM or analog (0…Vcc for 0…360 degrees). 12-bit (or 14-bit) resolution should be sufficient.

Hey! Much has happened since I have been here last time. :slight_smile:

Your appraoch looks good.

Regarding the potentiometer: I dont think this is neccessary. The only thing we would need (okay, I agree for this it would be pretty handy) is a starting position. If we align the axis in the neutral position on initialisation, you can do everything else with the encoder. This is also much more precise than using the potentiometer. My thought was to have a switch/sensor at the neutral position to initialize. Similar as on CNC machines.

Voltage: In the final code you should use 48Vpp as this only would increase the maximum torque the motor can apply. You will still be able to apply very little torque. To be fair, for testing purposes it would be wise to limit the voltage. In case your code goes nuts :smiley: In general, these motors are normally current controlled.

Rotational resolution: The motor you have is a three phase BLDC stepper motor that can be driven quite precisely. The keyword here is microstepping or current chopping. With this, you can basically move the axis without any jitter on the poles. You basically transition from one pole pair to the other very smoothly by chopping the current of your square wave into a sine wave at a few khz. Similar principle as used for stepper motors. Whats your control and PWM frequency you are using? Do you have a oscilloscope plot of your current curve?

Controlling the motor: What you would need to to is basically the following (sorry if this has been already explained by others (in possible a better way):

If you want to simulate a small force (on ground, low resistance):
Your motor is powered at lets say 50% torque.
The Motor is static at Position is 0° (you are not changing the commutation of the field)
The user wants to turn the yoke to the right and applies a force to do so. → Reading out the encoder tells you that the angle of the axis has increased by 0.01°
As you want to simulate no/small force, you change the electrical commutation of the motor by 0.01°

→ As you track movement of the encoder with your motor there is virtually no torque applied to the yoke.

Similar when you want to increase the force
->Encoder reads 0.01° deflection
->You set the commutation of the motor to -0.01° (depending on the motor geometry).

The first step is to control the motor precisesly using the chopping/microstepping technique (so you are able to set rotation angle and speed). The next step is introducing the closed loop PID control (while trying to not oscillate and making your table do backflips :D).

I have not been able to make any progress on the hardware side. Maybe I will find some time on the weekend. :slight_smile:

Cheers

Hi @tsaG13374551 , nice to see you back.
Much talk, but not much progress, I’m afraid.
I’m a bit busy today, but I have just a question for you and @MikeSierra2030 : while I was searching for motors and encoders yesterday I found also the closed loop stepper motors, which are stepper motors with the encoder at the back. Main advantage: I can buy them.
But I could not figure out if they are fit for this application.
They say that BLDC are better for torque at high speed, but I’m working stalled, basically.
Do you know anything about those?

Hello,

try attach some basic stepper (for few bugs sell) and you’ll see difference to DC motors, especially in case of need anti forces. Servos are very common also but need be strong enough also. Where strong anti force is required, I’ll be omit DC motors, also with encoders attached. My opinion…

1 Like

Hello,

sry only one example, I have here one basic stepper attached to my Arduino (I have my dashboard magnetic compass functional) via my C++ bridge app and I can tell you (it’s 40 steps) that with anti force it feels not ok, it feel very hard when I push to it and I feel teeth very strongly (actually not to your use) but I recommend for first tests with cheaps products and take skills about possibilities. Sry, hope I see this very simple, in case I have some existing FF device (yoke, car wheel,…), with inside motors/servos all can be quickly sorted what products can be +/- ok to my project. That my stepper is good precise enough to my app with magnetic compass :slight_smile:

Sry :slight_smile: I’m looking to your topic with big respect and enjoy your effort and power for this :slight_smile: very perfect!

1 Like

You have explained the rule quite well, but the change in angle by 0.01 degrees is exaggerated :slight_smile: You would need an encoder with 16-bit resolution to measure it. The same resolution would be needed for controlling the phase change. In practice, the resolution of 1/2 degree may be sufficient.

Similar when you want to increase the force
->Encoder reads 0.01° deflection
->You set the commutation of the motor to -0.01° (depending on the motor geometry).

In general, you don’t have to apply the same amount of angle to commutation. To the new value of commutation angle, you can add anything in the range -90 degrees … +90 degrees of electrical phase, depending how much torque you want to apply as the force feedback response.

Stepper motors could be used in this application, but there may be a problem with their number of poles. For example, a typical stepper motor used in printers, has got something like 50 poles, that is 200 steps in one physical revolution. One step rotates motor by 1.8 degrees. When the control loop is not very fast, let say 100 Hz, there is the risk of external force (pilot’s hand) rotating the motor by more than 1.8 degrees between control loop runs (quicker than 10 ms). In such scenario the control loop won’t be able to follow the motor movements and some magnetic pole jumps would be felt instead of a smooth action. IMO it is much easier to handle it with BLDC motors.

1 Like

It looks only, because it doesn’t work :sweat_smile:
I can’t get the phases out correctly.

yes, and here is where I would like to know… how did you plan to install the encoder?? I have (in theory) got the same motor as you have, but there is no way to mount an encoder on those.
I have removed the back yesterday to see what could be done on that side, but there is the hall sensor mounted there and I’m pretty sure an extra magnet for the encoder that @MikeSierra2030 was suggesting would mess up with the hall sensor.

Sure, I see that the potentiometer is not good enough. But are you planning to put an encoder connected to the motor on the timing belt?

Yes, and even with 12V limited to 1A I have fried already a set of mosfets :sweat_smile:

PWM is at 30KHz, control at the moment isn’t working so I can’t say. But it can be fast, the microcontroller is working at 40MHZ (instruction speed). I do have oscilloscope, but I don’t have current sensing yet, on the protoboard it would just be a nonsense, I need a real PCB for that.
I know in theory how it works, I have made circuits for a lot of steppers, so I understand how microstepping should work.
But with the stepper it’s easier, you have two phases on 4 wires. Here you have 3 phases on 3 wires, meaning that the switches on the bridge have to create six combinations of currents depending on the high and low switch configuration. Which, again, I got it with the trapezoidal control, and it works.
But then it turns out that the sine control is not a sine, because you have two phases mixing up, so it’s the sine of the overalap of the two waveforms, and that has to be syncronized with the position of the shaft through the encoder -that I can’t fit- and go back two “quadrants” -why two??- to reverse the direction… what a mess!
And the worse part is that I can’t find a document for the motor saying, for this hall sensor output, the phases have to be powered like this to go forwards and like that to go backwards.

Ok this is way more complex than I thought.

While I have no doubt that it’s the best that you can get, I’m still not convinced that it is really necessary for a yoke, where at the end, the forces are estimated by a third party software (MSFS doesn’t support FFB), where the amplitude is just a setting that anyone can change, where the force is set with a 8 bits value in most of the cases.

I will keep searching to see if I can find a suitable encoder or a servo motor, and how to implement the sine control with my setup -even if the potentiometer is not precise, it should work up to a degree, while what I get is just rubbish.
But considering also the difficulties to find motor/encoder, I might change plan and try one of those closed loop stepper.

I understand.
I do see a big advance on the stepper: standard microstepper drivers are really common.
But I’ll try to see if I can drive these BLDC since I already have them… although the lack of a suitable encoder is a big issue.

I wish all you developing your own FFB solutions, SUCCESS.

It is obviously going to be a great ride, and a good learning experience for many of you.

As someone with a strong technical background in “Control Theory”, I will watch with interest, as you proceed down your paths of discovery & realizations.

Thank you :slight_smile:

And head-banging against the wall, don’t forget that, it’s the major part of the learning process at the moment :smiley:
I’m actually quite annoyed that no one ever mentioned all this stuff at university in the control theory courses.

Somehow, I tend to agree… With the Speed ranges we would use, this might be a way ohne could follow…

The advantage of having more poles would also be more torque at a smaller size :smiley:

One could use the closed stepper motor you mentioned but I dont need the controller that comes with it (I could only find the offers with the controller).
I would opt for a NEMA34 size motor ( Like this one) with an Encoder. I was thinking about using an AMT10 or AMT13 Encoder. This one could be directly put on the shaft. The Motor also does have a plug in the back so you could also use a different encoder.

This motor is rated at 7.7Nm (which of course be reduced when you move)! I will Check the required rudder forces on the weekend but if its in this area, we could also go with direct drive. :thinking:

I think I will order this combo and give it a try