ODrive for force-feedback glider simulator controls

[cbrunschen]

This is related to, but also a bit different from, the Force Feedback Flight Yoke project.

I fly gliders. For training purposes, my gliding club is trying to build a simulator with a mock 2-seater cockpit (similar to the ASK21 gliders that the club uses for instruction). There will be a cylindrical screen and 3 (or possibly more) projectors, the mock cockpit in the center.

To get a good feel for the controls, and the interaction between instructor and student, they will likely be built much like the actual controls in a glider - physically connected together between front and rear cockpit, and resulting in movements of either push rods (for elevator, aileron and airbrakes) or steel cable (rudder) - there are some instructive diagrams in the ASK21 maintenance manual. Of course, for a simulator cockpit, everything behind the cockpit can be immensely simplified into something that can be connected to a sensor (to report the control position to the simulator) and a motor (for offering some form of force feedback).

The ODrive of course offers both a position measurement (the ‘pll_pos’ value that can be read back) and the option to apply some suitable amount of force (depending on choice of motor, etc) by specifying the current to provide to the motor – if I understand correctly?

The suitability of this solution also depends a bit on the rates at which the position measurements can be read back from, and new force-feedback instructions can be issues to, an ODrive or two, but over USB I don’t believe that should be a huge problem.

Another thing is that it might be useful to have a different kind of calibration option, where the absolute position is relative not to an index pulse, but relative to the physical range of motion that is available – perhaps if it were possible to detect when there is resistance against a motor moving further in either direction, and allowing one of those limits to the range of movement to be used as a substitute “index” of sorts, to define position zero – and possibly even allow reporting the available range after calibration.

(As a small aside; only three of the controls really need force feedback - elevator, ailerons and rudder - so a variant of ODrive that offered three axes would have been useful, and possibly less expensive than buying 2 ODrives, which would also leave one channel ‘wasted’. I’m guessing a 3-channel version of ODrive could also be useful for any kind of 3-axis CNC or similar but I understand that ship has sailed ).

Thoughts?

Best wishes

// Christian

[madcowswe]

The ODrive of course offers both a position measurement (the ‘pll_pos’ value that can be read back) and the option to apply some suitable amount of force (depending on choice of motor, etc) by specifying the current to provide to the motor – if I understand correctly?

Correct. And yes it should be able to be done at 500Hz or higher.

if it were possible to detect when there is resistance against a motor moving further in either direction, and allowing one of those limits to the range of movement to be used as a substitute “index” of sorts, to define position zero

Both this and use of actual switches to detect the “home” position is a feature that is high up on the todo list.

Cheers

[cbrunschen]

Thank you, that’s great to hear!

// Christian

[castle]

Hi,

Just set up an account.

Also interested in developing a force feedback system for my full scale 737 simulator and considering the odrive board. Couple of old videos on youtube under “737castle”

I’m curious about your description. Are you wishing to simulate the control loading on the stick as a function of the aerodynamics of the glider in flight and the dynamic pressures on the control surface as a fuction of Q, g-loads, etc which would be provided by a flight simulation program such as X-Plane, FlightGear, or P3D?

With out going down into the weeds on the subject, if that is the case seems what you might want is to have the simulator hardware (e.g a sensor, optical, Hall, elector-mechanical) report the positions of the control inputs to your simulation program which would than calculate the “free” positions of the control surfaces and move the joystick and rudder to that position. In turn, the student and/or instructor would then resist that force or apply a trim function to reduce the force or move the controls to the position(s) to achieve the desired flight attitude, send that to the simulation program, calculate the new flight dynamics, adjust the control loading, and move the joystick and rudder accordingly… In turn, you would vary the force required to move the controls to the new position based on the airspeed, g-load by adjusting the torque.

running the control loop at 500Hz might be excessive. 100Hz is more than adequate even for high performance CCV classes of aircraft

Since you all are pilots or soon-to-be pilots am assuming this is helpful. If not my apologies and I’ll fold my tent and go away and open a new thread. OTOH we might both gain by sharing. But before I do, have one question for the odrive folks.

Is python necessary to operate and control the BLDCs? Have no problem with that setup for design and testing, but need to write my own control algorithms for the flight control system in C++ and run in a real-time Linux OS, especially for such flight operations as target tracking, coupled Cat III approaches, and other autopilot modes.

Cheers
John

[cbrunschen]

The idea is indeed, as you say, to simulate the control loading (on stick, rudder, and possible air brakes) as a function of the forces on the simulated control surfaces, as the flight sim (probably FlightGear) calculates. Or at least, some approximation that is “close enough”. Even something as simple as (constant * deflection * airspeed) might serve as a first-order approximation.

Calculating the ‘free’ position is less useful: for the purpose of simulation, what needs to be calculated is the force that is acting on the controls, which can be calculate from the forces that are acting on the control surfaces. The pilot then of course has to deal with those forces as appropriate (resist, overcome, …).

This has to happen “quickly enough” so that it feels realistic. Anything above 50Hz or so would probably be sufficient.

[thendawg]

Have you guys considered the sim software integration piece yet? That seems to be the most difficult part. Ive spent some time with the USB PID for force feedback, but haven’t gotten too far. Ive started to consider writing my own plugin for XPlane 11 that could interface directly with the odrive. Previously I was looking at using an ATMega with brushed motors instead, but this seems like it could be a better way forward. BLDC def has advantages.

[Wetmelon]

Is python necessary to operate and control the BLDCs?

No, there are many ways to do it. We also support UART, step/direction, I2C, CAN, and I think someone’s even been using PPM or similar for remote control? I’d need to look at the code there…

[flyallthings]

Did anyone ever figure this one out? It’s very similar to the project I’m working on.

Could the position information from the motor encoders be used to provider position information from the joystick itself?