Thanks Darren....believe me I've messed with that stuff alot trying to get it to work. I'm using the DirectX joystick control to manage the Constant force on my Joystick. What I haven't figured out is cancelling the FF on the stick. There are also painfully few examples on the internet using FF. It seems nobody's doing this stuff. I've been really frustrated trying to get my 2nd axis to move...
HK, i agree, thats the trick, but is solvable in some fasion; I know it... I think the zero pwm value for the affected axis will move based on force ouput. So if its countered during the transition period, or isnt where it should be in time, then use the delta as rc-input-override.
To test FF try this link; (FF joystick and windows is needed), and feel what it feels like to have force set the stick to one postion, and feel the feedback of trying to move it another way. try this link...
When you run the application, it displays a window with a crosshair and a black spot in it. Click anywhere within the window's client area to move the black spot. (Note that moving the device itself does not do anything.) FFConst exerts a constant force on the device from the direction of the spot, in proportion to the distance from the crosshair. You can also hold down the mouse button and move the spot continuously.
the executable is availible in DirectX SDK, and Documentation is here:
@ Happy, I was talking about using the normal RC transmitter to control the plane so a safety pilot could take over if needed. Read binary serial data from the PC and maybe a head tracker and convert it to a PPM stream to feed into the transmitters trainer port. I don't understand why you would want the stick to move with the aircraft orientation. I would just want FF to be centered with the centering force proportional to stick position, and also ASp^2 . This would give the feel of a real plane.
That is the problem. There's no good way to eliminate the feedback loop. Since you've got 2 pieces of hardware trying to control the same plane, and the joystick has the ability to override the auto pilot, I don't see any way to eliminate the feedback.
In a situation where the plane is simply flying itself, and FF is enabled and the joystick output is fed back to the auto pilot, how can the FF input that translates into output be eliminated...especially when there's the possibility the user may be fighting the FF.
The plane goes into a bank. In this case, let's assume it's the max bank angle and the FF is told to go all the way to the right (let's say full range is -100 to +100). In this case +100. As the joystick moves, the current value is sampled, let's say 33,66,100,95,100 as there's a bounce at the end. The GCS knows a FF message came down and the message was to go to 100 immediately....but during those other samples where the value was not 100, should it have sent 100-33, 100-66, 100-100, 100-95, 100-100? So 66,33,0,5,0 during those samples? Or should the whole thing be less responsive so that the FF doesn't send the wrong signals to the plane?
As I was testing and starting to see this feedback loop, I started thinking the only value to FF would be for the "Gee-Whiz" factor of watching your plane flying in the GCS and the joystick moving...but the output from the joystick would have to be turned off. So if the user actually wanted to control the plane, they'd have to switch from FF to joystick output (with no FF).... Otherwise you'd get either a sluggish stick or oscillation.
I've been a force feedback user since what feels like the begining of time, I feel the use of FF is been left out of applications as it can be quite confusing for developers.
But that being said, I do feel the use of FF support in a GCS application, would be greatly received.
At minimal, assisting with setting the Stick Center function; for example using the "centering spring emulation" on those FF joysticks; as most are unlocked (free floating) and dont keep a good center when not physicaly held. For example even if I try to manualy center the stick, it tends to add input to the GCS when let go. Another workaround, has been to set the dead zone larger to compensate for the lack of a center spring
Here are two good uses that could effectivly affect the Stick Angle or Feedback responce:
Fixed wing) Lock the stick to the control surfaces: if the AutoPilot changes a paticular angle, set the joystick position to be the same as the control movements, thereby showing the change visually on an unheld stick, or felt on a held stick; also allowing for user input nudging or fly-by-wire. (see below for loopback comments)
Quads) Lock the stick to the attitude: if the craft changes angle, whether AP unduced or externally as in the gust of wind senierio. Match the angle of the stick to the attitude of the airframe, this creates visual change and or pressure in the direction of the attitude change when user holds the stick; and can even add more pressure if the user compensates by moving opposite of the angle change.
It is quite important though, the FF movement ouput must be removed from actual user inputs. Else a loopback can occour. This is the part that gets even the best application developers.
The best example of this happening is; if anyone uses FSX and has FF turned on, you can watch (feel) this same type of loopback responce.
Start with the stick left unattended, and FF settings are on, you can witness a loopback oscillation; where-as the position change of the stick postion (such as the gust of wind example), results in that movement being seen as user input; thereby exagerating the movement of the control surface in the SIM as it adds feedback ouput to user input. Complicating things is the centering spring emulation setting, which causes the stick to try and auto recenter. As it does, it creates opposite control surface user input. Creating an incresingly larger ossilation which can become anoying at least or bad at worst.
But... in the real world, with either meathod I mentioned above; it can be a very good refrence to situational awareness for the "Man on the Ground"
Imagine your UAV is flying along straight and level in route to a waypoint, and a gust of wind creates a new bank angle and a bit of pitch change. This change should be seen as movement of the stick (if not held,) or felt as pressure if held. But when the stick actually moves when it's not held, the application needs to ignore the postion change, so the actual movement of stick will not be detected as user input and sent it back into the Auto-pilot data stream, causing a feedback loop.
You can actually already use the joystick to control the plane with my GCS. Click the Joystick tab at the bottom left and hit calibrate. I'm already sending the outbound stream via MAVlink and the X-Bee's....or are you talking about another solution?
Should have watched the vid first. I thought it was just a joystick and software. I have that exact stick on my PC only without the FF. Here's a link to how it works. I don't like it. It does not simulate real pilot feedback. It does seem that it would create a positive feedback loop that would mess with the pilot.
Happy, If you could get and send USB commands from and to the joystick, and send out serial data from the PC at 50 Hz, I could program an Arduino to read the serial data and generate PPM signals to send to the transmitter thru the trainer port. I have some experience at this. I made a 6 ch trans into an 8 ch. using an Arduino. Two channels are for a head tracker sending serial data (ArduIMU flat). I can do Arduinos but not PC's. If you want to collaborate on this, PM me.
I don't think FF would apply to a copter. With a fixed wing it would work like this. From personal experience piloting a manned plane, zero airspeed means zero force to move the controls(except for the wight of an unbalanced elevator). As airspeed builds the controls get stiffer. A given input force on the stick produces less control deflection as airspeed increases. It works out good for the pilot because a certain input force produces the same control moment regardless of airspeed. With a RC system we loss this natural airspeed compensation. Servos go where they are told by degrees and stick force is just a spring.
We all ready have all the data to simulate the FF signals on the GCS, airspeed and control deflection. I think it might go life this: FF = K1*(Cin * K2 * ASp^2) , Cin = control stick deflection; ASp = airspeed; K1 & K2 are scale constants.
I purchased the same joystick....with the same intentions. I have not been able to wrap my head around how to make it work. If the FF is tied to IMU movement then how do you filter out the FF commands and not override what the auto pilot is doing.
Comments
HK, i agree, thats the trick, but is solvable in some fasion; I know it... I think the zero pwm value for the affected axis will move based on force ouput. So if its countered during the transition period, or isnt where it should be in time, then use the delta as rc-input-override.
To test FF try this link; (FF joystick and windows is needed), and feel what it feels like to have force set the stick to one postion, and feel the feedback of trying to move it another way. try this link...
When you run the application, it displays a window with a crosshair and a black spot in it. Click anywhere within the window's client area to move the black spot. (Note that moving the device itself does not do anything.) FFConst exerts a constant force on the device from the direction of the spot, in proportion to the distance from the crosshair. You can also hold down the mouse button and move the spot continuously.
the executable is availible in DirectX SDK, and Documentation is here:
http://msdn.microsoft.com/en-us/library/ee417552(VS.85).aspx
if you dont want to install the entire directx sdk to get the test program, its availible here
http://boat.lachsfeld.at/ffjoystick4java/ffconst.zip
edit: by zero pwm, I meant pwm trim values
That is the problem. There's no good way to eliminate the feedback loop. Since you've got 2 pieces of hardware trying to control the same plane, and the joystick has the ability to override the auto pilot, I don't see any way to eliminate the feedback.
In a situation where the plane is simply flying itself, and FF is enabled and the joystick output is fed back to the auto pilot, how can the FF input that translates into output be eliminated...especially when there's the possibility the user may be fighting the FF.
The plane goes into a bank. In this case, let's assume it's the max bank angle and the FF is told to go all the way to the right (let's say full range is -100 to +100). In this case +100. As the joystick moves, the current value is sampled, let's say 33,66,100,95,100 as there's a bounce at the end. The GCS knows a FF message came down and the message was to go to 100 immediately....but during those other samples where the value was not 100, should it have sent 100-33, 100-66, 100-100, 100-95, 100-100? So 66,33,0,5,0 during those samples? Or should the whole thing be less responsive so that the FF doesn't send the wrong signals to the plane?
As I was testing and starting to see this feedback loop, I started thinking the only value to FF would be for the "Gee-Whiz" factor of watching your plane flying in the GCS and the joystick moving...but the output from the joystick would have to be turned off. So if the user actually wanted to control the plane, they'd have to switch from FF to joystick output (with no FF).... Otherwise you'd get either a sluggish stick or oscillation.
I've been a force feedback user since what feels like the begining of time, I feel the use of FF is been left out of applications as it can be quite confusing for developers.
But that being said, I do feel the use of FF support in a GCS application, would be greatly received.
At minimal, assisting with setting the Stick Center function; for example using the "centering spring emulation" on those FF joysticks; as most are unlocked (free floating) and dont keep a good center when not physicaly held. For example even if I try to manualy center the stick, it tends to add input to the GCS when let go. Another workaround, has been to set the dead zone larger to compensate for the lack of a center spring
Here are two good uses that could effectivly affect the Stick Angle or Feedback responce:
Fixed wing) Lock the stick to the control surfaces: if the AutoPilot changes a paticular angle, set the joystick position to be the same as the control movements, thereby showing the change visually on an unheld stick, or felt on a held stick; also allowing for user input nudging or fly-by-wire. (see below for loopback comments)
Quads) Lock the stick to the attitude: if the craft changes angle, whether AP unduced or externally as in the gust of wind senierio. Match the angle of the stick to the attitude of the airframe, this creates visual change and or pressure in the direction of the attitude change when user holds the stick; and can even add more pressure if the user compensates by moving opposite of the angle change.
It is quite important though, the FF movement ouput must be removed from actual user inputs. Else a loopback can occour. This is the part that gets even the best application developers.
The best example of this happening is; if anyone uses FSX and has FF turned on, you can watch (feel) this same type of loopback responce.
Start with the stick left unattended, and FF settings are on, you can witness a loopback oscillation; where-as the position change of the stick postion (such as the gust of wind example), results in that movement being seen as user input; thereby exagerating the movement of the control surface in the SIM as it adds feedback ouput to user input. Complicating things is the centering spring emulation setting, which causes the stick to try and auto recenter. As it does, it creates opposite control surface user input. Creating an incresingly larger ossilation which can become anoying at least or bad at worst.
But... in the real world, with either meathod I mentioned above; it can be a very good refrence to situational awareness for the "Man on the Ground"
Imagine your UAV is flying along straight and level in route to a waypoint, and a gust of wind creates a new bank angle and a bit of pitch change. This change should be seen as movement of the stick (if not held,) or felt as pressure if held. But when the stick actually moves when it's not held, the application needs to ignore the postion change, so the actual movement of stick will not be detected as user input and sent it back into the Auto-pilot data stream, causing a feedback loop.
You can actually already use the joystick to control the plane with my GCS. Click the Joystick tab at the bottom left and hit calibrate. I'm already sending the outbound stream via MAVlink and the X-Bee's....or are you talking about another solution?
Should have watched the vid first. I thought it was just a joystick and software. I have that exact stick on my PC only without the FF. Here's a link to how it works. I don't like it. It does not simulate real pilot feedback. It does seem that it would create a positive feedback loop that would mess with the pilot.
Happy, If you could get and send USB commands from and to the joystick, and send out serial data from the PC at 50 Hz, I could program an Arduino to read the serial data and generate PPM signals to send to the transmitter thru the trainer port. I have some experience at this. I made a 6 ch trans into an 8 ch. using an Arduino. Two channels are for a head tracker sending serial data (ArduIMU flat). I can do Arduinos but not PC's. If you want to collaborate on this, PM me.
I don't think FF would apply to a copter. With a fixed wing it would work like this. From personal experience piloting a manned plane, zero airspeed means zero force to move the controls(except for the wight of an unbalanced elevator). As airspeed builds the controls get stiffer. A given input force on the stick produces less control deflection as airspeed increases. It works out good for the pilot because a certain input force produces the same control moment regardless of airspeed. With a RC system we loss this natural airspeed compensation. Servos go where they are told by degrees and stick force is just a spring.
We all ready have all the data to simulate the FF signals on the GCS, airspeed and control deflection. I think it might go life this: FF = K1*(Cin * K2 * ASp^2) , Cin = control stick deflection; ASp = airspeed; K1 & K2 are scale constants.
OK now get to work Happy!
I purchased the same joystick....with the same intentions. I have not been able to wrap my head around how to make it work. If the FF is tied to IMU movement then how do you filter out the FF commands and not override what the auto pilot is doing.
-
1
-
2
of 2 Next