Ah, Bosch Rexroth… I wonder how I could live without them 
This stuff is really fantastic to build structures.
I have ordered belt, pulley and stuff for the roll axis, and the second cable for the encoder. I’ll make the electronics to drive the motor in the next days.
But the linear rails are dreadful, hard and noisy. Not what I had expected…
1 Like
A corrected plate, with also the lock for the timing belt, the second stop with the hole for the switch and I’m almost ready to test to test the pitch axis. I just need to solve some very silly issue with the microcontroller and some register not updating when I’m not debugging.
The (brushed) motor runs unbelievably smooth. I hope it has enough torque to run without reduction. I have got on ebay also a Maxon, also no cogging, but smaller. If everything works, I’ll definitely get rid of the brushless and make the assembly a lot smaller, as it is now it’s too tall to be practical.
I still can’t figure out where the problem is with the micro (I can’t read the encoder except when I’m debugging, it’s such a nonsense…), but in the meanwhile I have put together the new parts…
I have tried the motor, which is rated 30V. I am using a 2A power supply, so I’m limited to that… and with more than 500mA (the voltage goes to a few volts) I can’t move the yoke! There is plenty of torque there, and the movement is completely smooth (except for the dreadful rails, I’m definitely going to get rid of those).
Now I need to find the way to get the encoder working (I’m using it instead of the potentiometer) and I will be able to receive the torque setting from the main board with the USB and the main program.
New design with brushed DC motor and new linear rails… a LOT smaller. I’m using a 60 teeth pulley on the axis and a 20 teeth pulley on the motor. The pitch axis remains as it is now.
Here is the new design, now it moves smoothly. See from the front how much height I have gained from the previous configuration with the brushless motors.
Unfortunately I have made a mistake on the big plate and the timing belt isn’t as smooth as it could be, but since it takes 12h to print that part, I’ll keep it as it is for now.
I have checked the motor on the roll axis, with 2A it is just strong enough to give a good feedback.
According to the characteristics
VALUES AT NOMINAL VOLTAGE
Nominal voltage 48 V
No load speed 7590 rpm
No load current 68.6 mA
Nominal speed 7000 rpm
Nominal torque (max. continuous torque) 187 mNm
Nominal current (max. continuous current) 3.17 A
Stall torque 2560 mNm
Stall current 42.4 A
Max. efficiency 92 %
I could reach 3A continous. It should be ok, but it’s definitely on the lower limit of the motors that I could use here.
One consideration. If you look at these specs, you have >42A of stall current. When it’s stalled -which is how it will work 99% of the time- the voltage with 2A is 3V. I have never considered that you need volts for speed, but just amps for torque when it’s stalled.
So there will be no need to go for a 40-50V 10A power supply, it will be sufficient to have a low voltage, even 10-12V, high current power supply.
Well today I had a little trip
This is a Cessna 152… a bit of a paper airplane, especially with the wind we had. But anyway, the important thing that I have noticed are the forces on the yoke.
I would say that on the pitch axis I have plenty of margin, it never reached the force that I feel with 5-600mA on that motor. On the roll axis, with the motor/mechanics I have, with 2A I am a bit short of torque. Not unusable of course, but not realistic either. I´ll have to try it with 3A at least, but it would benefit a bigger motor.
And the size of my little test yoke was surprisingly similar to the real one, that plane is really tiny
1 Like
A lot of tests have been conducted during the last weeks. A standard PID controller can be applied for haptic bldc motor, but since I want to dynamically adjust the force gain (yoke should be stiffer with increasing airspeed), the motor stability becomes a real challenge. So finally I applied the technics known from many bldc SVM drivers: using inverse Park transform, which allows me to set direct and quadrature components of the magnetic flux vector independently.
The quadrature component gives the torque proportional to the motor deflection from the reference position. The direct component is being set proportionally to the speed of motor movement and assures stability.
Here is the roll action with the device connected to the simulator:
When the autopilot is on, the pilot’s input is not sent to the simulator. Instead of this, the integration part of the PI controller for the quadrature component is turned on. This is the action with the autopilot switched on:
The integral part of the PI controller partially solves the motor cogging issue. Eventually, I will use the motors with a lower cogging effect.
1 Like
That is quite impressive.
I guess you are using your own program to interface to yoke with the flight simulator?
When I was trying the BLDC I had a lot of stability issues with the integration part of the PI controller, it was oscillating and overshooting wildly as soon as I was applying some meaningful value.
But you are doing a huge work…
I have removed the BLDC for now and gone to plain DC motors. Zero cogging and no complicated control
I’m working on the PCB with the driver for these motors at the moment.
I’m seriously enjoying this forum, I’ve been struggling firmware side of things and its impressive to see how far ye’ve all come. Are ye planning on releasing the firmware and making an official OpenFFB flight firmware for everyone? Would be nice to have a solid working software that everyone can use
I’m currently building a FFB yoke using the MSSFFB2 stick “stuff”. Is what you are making different from that in some way? Or is it that you want to have your own design?
Well, this is more a question for @MikeSierra2030 , as when I started I wasn’t aware of OpenFFB and when I started looking for it I couldn’t find any of the information I was looking for so I ended up with my own design.
Also my architecture would be a bit different, because I’m going to have an interface board, with all the dreadful USB stuff, and one board for each motor that will implement the effects and talk with the USB board. Also, in my original plan, there is also the possibility to plug together two yokes to fly a plane together with another person.
Nothing is decided yet, but I don’t think that anything I have done is compatible with OpenFFB.
I did start this work looking at those projects, then a number of reasons made me go for a full custom design.
- “recycling” the electronics of a stick would have limited a lot what I could do, as everything would have been already hardcoded in there
- reading here and there, it seemed that the motors were too small for a yoke
- in my idea, as I mentioned above, I wanted to implement things that do not exist on a normal stick
- not secondary, I couldn’t find any ffb used stick available at a reasonable price here
- I’m an engineer, I need to complicate my life
2 Likes
And this must be the essential reason.
I’m an engineer too, and usually developing things myself is easier for me than borrowing and investigating other’s solutions.
1 Like
It is indeed!
Well, here are my boards, still warm from soldering iron
No deadly shorts, so ready to go tomorrow to load some code and check them out.
They have the driver for a brushed DC motor with a temperature sensor, the input for the encoder, two limit switches, two spare potentiometer input (just in case), a capacity sensor circuit (another idea I had in mind, reduce the torque when no one is holding the yoke), RS232 and SPI for the connection with the main board (still haven’t decided which one to use, SPI would be better to use one bus only, but I’m not sure how far it would go outside the board).
Time for fun now…
1 Like
I noted the 3D printed components that you are using for the main support structure. How are they holding up? did you use PLA, PETG, or ABS?
I used PETG for my collective. It’s holding up well but it doesn’t have to deal with the forces of FFB. I’m thinking of trying my hand at ABS if the added strength will be needed.
My design is different from the sliding gantry that is generally used for a yoke. I’m a mechanic (for 40 years) IRL and wanted something more compact with a lower parts count. The last of the parts I ordered should be here this week so I hope to begin assembly next week. I’ll add some pics when it starts to look like something.
Ah, yes, very good point. I was very worried about this, I prefer working with metal but I don’t have the tools/space at home to do it, so I had to limit myself to 3D printed part.
I have a cheap printer (I got the very first one last year, never had it before and didn’t want to spend too much money on it at the beginning… now that I see that I’m printing like if there were no tomorrow I’m thinking to get something better) and I work only with PLA.
When I started studying what was around for this project I read comments about 3D printer parts not being solid enough for a FFB yoke. I agreed in principle -I trust more a solid 3mm aluminium plate than any piece of plastic-, but having no choice, I had to go for PLA.
Said that, I’m positively impressed. I’m not sure on the long term, but right now all pieces seem to be solid enough for this work. I’m printing with a generous filling (the main plate took 12h to print) and there is no sign of bending.
I haven’t tried yet at full power, but I have the feeling that the amount of force expected by a yoke has been a bit overestimated also in this thread and in other projects I have seen online. The motor doesn’t need to be able to break your arm, basically
So, for now, PLA with a reasonably oversized design seems to be working, as long as there is a solid structure around it (my Rexroth frame, for example). If it will give problem with motor heating, humidity over time, etc., that I don’t know.
Ahh that would be fantastic, if you could share some idea! I gave a lot of thought about the mechanical design but I could not came out with anything more efficient that this classic design, mostly because of the limitation on the tools that I can use.
One of the ideas I had was to to have two pipes, one free to slide inside the other (for pitch), but linked together for the rotation (roll). In this way all motors would have been fixed, no high inertia due to carry the roll motor with you, no bearings and less parts. But again, as I can’t work metal, even less metal steel pipes, I had to drop the idea. I still think that there was a good potential for that.
Circuit is working (yes, I’m surprised ), after some debugging I have passed part of the code from the previous prototype (the USB board) on this board and I have started to implement the effects with this new setup.
The main difference is that, instead of reading a potentiometer, I’m using the encoder for the position. Being an incremental encoder, it needs to be initialised when switched on. In this video you can see this operation: the program starts and it moves from one side to the other, touching the switches and setting the limits.
Then, using the spring effect, it goes to the center -and stays there, that’s where the code ends at the moment.
The control is a simple proportional, with a detail or two (I’m limiting the increase in PWM to avoid the “slam” when I set the central position and the yoke is at an extreme, for example). Mechanics is smooth-ish but I’m not satisfied (I made an error with the distance between pulleys and I had to sort it out with a patch, so it’s not as smooth as it could be). Still, even without the proportional part, it goes back to the center reasonably well.
And no cogging 
This board controls one motor only. The other board will contain the same code and will be connected to the other motor. I have the circuit for the current reading (and it work, I can read the current), but at the moment I’m not using this feedback for the PWM. I had it there “just in case”, but it doesn’t seem that it’s needed for the control itself. I might keep it for safety to detect overcurrent.
1 Like
I’m doing a bit of development stuff to test the code. I have decided to go with the UART link, the micro with the USB that I have been using has four of them, so plenty of stuff.
I am doing a simple interface in labview that will let me send the same packets as the USB board will do, which are nothing more than the packets received from the USB. You might recognise the reports if you are familiar with the USB protocol for the FFB:
I have just started yesterday (so much time has passed since I made something in labview…), but it’s coming up nicely. Constant force already works, now it’s just a matter of putting the rest together and add the reception of the yoke position.
Here is the further haptic device development. This time I’m testing the medium-sized gimbal motor HT4315. It is built in 24n28p configuration, which promises a smooth operation. And it is indeed. I’m going to use it for the throttle lever.
The most difficult thing to develop was the dual-side operation:
- the lever is moved manually and its position sets the throttle lever position in the simulator
- the throttle lever position in the simulator is being moved by the mouse pointer and the motor is moved respectively. This way the lever should nicely move with auto-throttle mode on.
The race hazard during these dual-side operations was the most difficult issue, but it’s solved now by a smart procedure.
1 Like
I’m curious, what is the advantage of using a brushless for this kind of control, compared with the use of a DC+encoder/potentiometer? I guess you need an encoder also there anyway, to read the position and to have a fine control, no? (ok I sort of answered myself while I was re-reading my post, I guess with a DC you need to control the torque to reach a certain position while with the brushless you can apply full power and it will stay there until you move the phases, right?)
If you control can give the setting to the PC and be controlled by the PC at the same time, how have you solved the conflict when you are moving it from either end (PC or control) and the other side has not reached yet the new position? I’m interested because it’s the same situation that I will have to deal with when/if I will implement the possibility to link together two yokes.