I want to just keep things in context so you don't take this the wrong way. First, I understand it's a shift in thinking - I read Leo's document and half of it made sense, with the other half seeming to be a rambling mess with some strange statements and diagrams that didn't appear to illustrate much. It's actually not until I've been discussing the merits of the concept that it's started to fall into place and some of those diagrams and statements are making more sense to me. I certainly don't think Leo's helped himself with the format of the document - the whole trike thing takes it out of context, albeit in an effort to simplify things. Second, Spaskis, you're starting to ask questions about implementation. As I stated above I have no experience with simulators and I have very little knowledge of the hardware involved. I think it's unfair to start bombarding me with questions about how to design a controller when 90% of your responses to the idea in this thread have attacked the underlying concept of position feedback; here are some concatenated quotes from yourself: I'm not championing position feedback as the holy grail of controller feedback; it's difficult to think it through from start to finish but undoubtedly any system will have latency somewhere so while this concept might move it out of one area and reduce/eliminate oscillations (for example) it's bound to have some issues elsewhere. I also agree there would be difficulties getting a clean input force because you have to measure 'behind' something that has its own mass and inertia. (I'd imagine you'd want to measure as close to the user as possible, so maybe measure the force applied to the wheel grips/rim relative to the wheel itself; but I digress) If you want to accept the principle of position feedback then sure, let's talk about the shortcomings in a practical application. I've only ever tried to defend the underlying concept so I have no reason to argue with anything you'd be able to shed light on in that regard. But if you can't accept the principle then let's discuss that. No, I described simulating a single spring and described how it could be done step by step; you keep getting to the first step (force applied to a centred spring without mass) and say WRONG! Can't be done! and I keep saying I know it doesn't make sense at that point, but if you still react to it with the controller and then keep reading in the input force and calculating a new position it will progress in a roughly intended manner. Increase the frequency of updates and it improves. You never showed how my step by step example doesn't work - you just keep stopping at the beginning. Finally, please - understand no one is saying you can read a force from the user and say "ok, because of that force the wheel needs to be in position X". The user force is put into the system and the new wheel position is calculated from the system. Let's say in the middle of a corner the tyres and geometry are pushing the steering wheel to the left. The driver is applying a force to the right, so that the wheel isn't moving. In force feedback, this balance is happening directly at the user. His wheel is pushing left, he is pushing right, the wheel doesn't move. The game reads the wheel position, which isn't changing. In force input, the virtual front wheels are pointing to the right X degrees, so the virtual steering wheel is pointing to the right Y degrees. That is the position the controller is set to. The user is then applying his force, which the game reads. It calculates the force coming up from the tyres and geometry to the steering column (pushing left) and adds in the detected force from the user (pushing right) and they balance. The virtual steering wheel therefore doesn't move, so the controller isn't moved either. As a static condition this all adds up. What I think you're then doing is saying, "But how can it know how to react with a change in input force? The wheel is being put in a position by the game, so increasing or reducing the user force will have no effect; the user is pushing on something that isn't moving, it makes no sense." This is where it comes back to the update rate. As soon as the user starts to reduce the force they're applying in our example, the game sees that reduction. Now the tyres + geometry are still pushing left as before, but the user force pushing right is reducing. The virtual steering wheel starts to move left because of this imbalance. Therefore the controller is told to start moving left. The same thing happens again next update: the user force is read and applied to the virtual steering wheel, as part of the entire system. The new virtual steering wheel position is calculated based on the balance between its input and the input of the tyres + geometry, and the controller is told to move to that new position. As I described much earlier, at low frequency this will be a horrible mess. It's quite easy to imagine that. But if you update it very quickly it will surely smooth out, and probably start to feel fine at a certain rate. This is the concept you're refusing to let yourself understand. Again I'm not judging its practical performance or the ease of its implementation, but that hasn't been the topic of our arguments.
Lazza apologies for my way of expressing. I strongly appreciate your will and explanations although I simply cannot figure out how to explain myself in any other way. It would be stupid to discuss forever since as some other say we both want the same thing: the best FFB. Our ideas have been widely explained and people for sure have got the point of each. What I will do next when I get back home is to do the tests that I said and make some videos to publish in this thread to show the things that could be improved within rf2 in terms of FFB. HOPEFULLY, Isi will post in this thread some day and put some things on the table about which things in their opinion can be improved or ar not simulated at all and if PFB makes sense. The opinion of any FFB device manufacturer would be strongly appreciated. Thanks for the interesting discussion. Enviado desde mi GT-I9505 usando Tapatalk 2
No need for apologies, nothing wrong with robust discussion I hope I've remained civil in my replies as well. For my part I think my previous post has submitted the concept about as clearly as I could hope; as usual most of the battle with forum discussions is trying to communicate what you mean. I would say the current FFB, and the philosophical question of whether FFB should be 'raw' or enchanced, has at times overtaken this thread which was originally about Leo's idea. But we've probably given the FFB vs PFV discussion a good run for its money so going OT probably won't hurt too much. I do hope you, Natureboy, perhaps speed1, and anyone else confused about Leo's idea take the time to read our discussions and understand the way in which it would work. The various impracticalities and imperfections are perhaps for another discussion.
I take interest in this thread because there is good conversation here. Leo's statement that the wheel needs a position component in its communication with the game is very understandable. His idea gets very confusing when he talks about the force from the user being the input. And, as indicated by another member here, Leo told him that the feel of the wheel would not really improve with his idea but stability would. I have worked with Fanuc robotic arms using the best stepper motors available coupled with rotary encoders consisting on roughly 32000 divisions/360deg. With these you can have the arm pick up a load, then swing it in the air and the software will very accurately measure accelerations and power input to the motors and be able to calculate mass as well as moment of inertia for the load. Certainly, stepper motors are capeable of providing very intricate and accurate force to a load while driving it on a specific path. The problem I have with the stepper motor driving a steering wheel strictly by position - as I understand Loe's idea versus being driven strictly by force - is that the driver is always able to place the wheel in any position desired under normal conditions (driver dictates position). So, if going through a bumpy corner and over curbs, and the driver holds the wheel at a constant position, then since the wheel is working on position, how are you supposed to feel any difference in forces? To drive extra current or voltage into the motor and increase the force there must be a position offset that the motors are trying to drive to. So unless the game is going to allow your steered angle to change in game without your physical wheel angle changing, I cannot see how the wheel can feel even close to real. And, if the game has changed your wheel position without a change in user input then that is very incorrect. With force being the driving factor all of those bumps creating forces which try to change the steered angle of the wheel are relayed to the driver. Any forces that make a torque on the steering wheel can be relayed to the driver and operation is proper, the driver dictates what position the wheels are pointed. As I stated before the wheel does need to be aware of the actual position of the wheel in game. So, when the driver is holding the wheel, the in-game position corresponds to the actual wheel position. When the driver lets go, FFB from the game is now driving the wheel, but force output needs to be zero and the wheel needs to move in position corresponding to where the game physics say the wheel would go. Again, wheel position must always be consistent. This would stop any oscillation due to large FFB forces throwing a light wheel all over the place and overshooting the position that the wheels would normally go to.
It may not be a linear relationship between steering wheel angle and steered angle, but it is a direct relationship - unless we are talking steer by wire. Nevermind anything to do with vehicle dynamics, the only thing a driver can physically do with the steering wheel is change the steered angle of the steered wheels. That is as simple as it gets and as long as there is a mechanical connection it is fact. Please let me know if this is wrong.
Well... Here is Leo's idea in working principal. Was looking into steer by wire and found this: http://www.steer-by-wire.info/Working Principal.html Here is an article outlining a position based system with FFB as we have in-game. This one is less clear than the last since its a general case, steering info starts at pg 16: http://www.google.ca/url?sa=t&rct=j...Vk7-aDpKCthZNrr7KCP3hnw&bvm=bv.53899372,d.cGE and another with PID position control: http://robot.kut.ac.kr/papers/ta08-3.pdf Articles out there on various cars with steering by wire give different perspectives. The reaction to driver input can be instantaneous and some authors mention that feeling as good, while others state that you have virtually no feel for the road, but of course vibrations can be filtered out of the feedback. No article I have found yet on a specific vehicle states wether driver input is position or torque based, but I do suspect car companies have gone torque based because of the obvious advantage of system stability (where the system knows when the driver is not holding the wheel) and that this is really a motor control problem above anything else. The torque based system uses a self locking mechanism that holds the steering wheel in position, a torque measuring device and the position feedback motor to move the steering wheel to correspond with the actual steered wheel angle. So I stand very corrected, the position motor can relay all forces to driver while articulating the wheel since the drivers torque is measured separately from the motor. The forces supplied by the PFB motor are related to the forces exerted by the rack driving motor to keep the wheels at their current position, and if the drivers input is more or less than needed the wheel moves and so do the steered wheels. I think everyone here can agree that steering torque and steering angle or path of the steered angle are intricately related, although they are not exactly the same. Force input with a reliable position output does work and can have accurate feedback. But man, is it ever a complicated idea to turn the system backwards. Sorry to fill up all this space, control type problems always seem to contain interesting and odd (to me) type solutions. Thanks
Lazza wouldn't it make the whole steering feeling stellar ? I mean reading out a resistance appyling by the user to know the pushing force from the tire/wheel to move the steering would clean out all the vibration or not ? Is this wished to feel just the dominant and pure pushing forces. What about the intereferences between the medium tire/rubber and surface ? Wouldn't it eliminate all the oscillation ? It was not realistic even if we don't feel every little interference/vibe/deflection, it is present in real. Not sure how it would feel and if it would accepted by the user to elminate oscillation physically. Better solution was to simulate and let behave the output right, not re-controle or eliminate it because of any fault in the simulation or what else. As for the position differences, there are constantly direction/angle differences between input driving direction and tires/wheels rolling direction. Wouldn't this mean there is no force generated because the little slip angle differences aren't taking into account because the system doesn't realise a position and force input ? For me it sounds like cutting natural physic behaviour when trying to controle by input force.
That's not the sort of oscillation I was talking about. If you let go of the wheel it is likely to oscillate when a force is applied, because the wheel's own inertia moves it past centre - which makes the game push it the other way, and then it goes past centre again, so it pushes the other way... etc etc. This whole idea isn't about reducing 'real' forces at all. You've got the wrong end of the stick on that one. What I don't know is how the feedback would compare with this system as compared to current FFB, but there's no attempt to filter or 'clean' the forces here. *Reading your post again, no, no, and no. This system is not about reducing any incoming forces at all. You're misunderstanding it.
Language is an issue Leo's idea would still give you all the same feedback as FFB would give. You might not notice any difference at all. In some cases it would help, yes, but not by cutting out anything the game is trying to give you. It would help for sure when you're not holding the wheel - how often do you do that when driving? It might be great, it might be nearly the same as current FFB. I can't say without trying it, and that's not going to happen anytime soon. All that matters to me right now is we understand that it can (and does) work, even if it seems very strange at first. *By the way, nice find there Natureboy. That's saved a few more potential discussions
You're right the language is a issue and yes it would be intresting to feel it and to hear from a pro. Actually i could manage to drive rf2 on my second pc with a HD5850 on TV. With some compromises gfx wise it still looks pretty good. I would like to test the new cars and for test purpose i use the G27 instead of the T500 and what i could feel was not perfect but already very good. There is really not much missed on rf2 ffb, even the G27 ride with the G4 was impressive. Yes some details could be better and everything what can improve it is welcome.
The G27 is boring compared to the T500 while it is weak but more direct the T500 is more powerfull but its own resistance is to high and feels to damped. The more bad is to feel the (T500RS) cogging of the motor. Both wheels are not good enough. Now how can this be changed by the software ? Or is the software the reason for the bads ? Don't know, for me this wheels are more or less toys, the one more than the other. Based on this conditions some things could be better but i'm not sure if the driver should be able to feel raw physics or just main forces like in a real car. I guess it could be boring to feel real for user without motion rigs.
https://www.dropbox.com/s/ouh3w7pp6jjpioi/FFB testing ramp.png The ramp is ready for testing. Hopefully later I will do some testing. I hope dimensions are OK to leave the Clio and some others with 4 wheels free.
