Prototype Pitch & Roll Full Rotation

http://web.cs.wpi.edu/~claypool/papers/precision-deadline/tr-06-13.pdf

For those that are into reading technical articles..here is a good one about latency. It states that above 50 ms total, research data indicates slower lap times. Given ping times often at or above that figure..every reduction in other areas theoretically make better lap times possible. Given that many iracers practice 10-20 hours per week to improve 0.5 seconds per lap, you can see how important it can be to the really serious players

Iracing guys like to benchmark each other as to whos has more PFS per second

For a given GPU, decreasing video quality/output incerases FPS. For a given video quality/output spending more money on a GPU generally gives more FPS. Without disclosing the video quality/output, benchmarking FPS seems silly. If someone tells me they have three monitors with high resolution and 100 FPS..then I would be impressed by how much much money they probably spent..sort of like being impressed by a Ferrari. Are they faster on the track??.perhaps not. The only benchmarking I care about would be lap times.

ISRTV is the place to look up iracing FPS comparisons

I can’t tell you what fps I get with iRacing because I don’t use it. So far, I have refused to pay their asking price when I have so many other titles to choose from that I can purchase outright! I use Nascar Racing 2003 season instead. Its code is what iRacing was built on in the first place.

I’m not saying iRacing is not worth it though because Papyrus was the best imo when they were in operation.

But I’m not really concerned about what my frame rate is to be honest. If it were to slow, I would know it, and then I would concern myself about it! I usually just vsync at 60hz and I do know I get 60 fps. However, I don’t know if the gtx 770 in use (PNY XLR8 Enthusiast Edition) would be able to keep up with 5760 x 1080 in 3D because that would be the equivalent of 11520 x 1080 in reality if my understanding is correct.

Btw, after some research, I am convinced that the human eye can see many more fps than 24 because it doesn’t see in frames, but is continuous. However, I am also now under the impression that the human brain is only capable of processing between 12 to 20 fps. But, while it many not be able to process every frame over 20 fps, what you are able to process will be using the most updated information possible when using the fasted frame rate possible.

I equate that to our simulators. We want to have the latest telemetry update possible when it comes time to actually process it!

ps I also run just about everything maxed out in the games settings but I keep anti-aliasing to x8.

BlazinH...Thanks..as usual..a thoughtful and informative response.

I like triple monitors but so far have stayed with one big one to keep my FPS up. I do not Vsync and have not noticed any tearing. Your set up is very nice and got me to reevaluating the triple monitor option using a GTX Titan. Still ruminating over lag time on monitors or projectors. The low lag 120hz monitors seem to be in the 27 inch area and would need to be pretty close to my face compared to 60 in monitors or projectors.

Thanks again..I think I'm off topic so over and out...Happy Thanksgiving!!

its difficult to actually see FPS difference when you are in a motion seat

http://www.maketecheasier.com/4-myths-about-computer-monitors/

Using the oculus rift with my laptop I peak at 45 FPS and generally run at 30 FPS. Motion sickness kicks in pretty fast at these sort of frame rates. I may not be able to tell the difference on a standard monitor but the immersion is truly broken on the rift. I can only imagine this would get even worse during motion simulation (just guessing here, no hard data yet). This is why I needed to buy a high quality GPU. The minimum recommended FPS is 75, and the commercial release is expected to aim for 90 FPS!

I initially found that synchronised motion helped in reducing motion sickness with the rift. Although I don't suffer at all now.

PLS explain what you mean by "synchronized motion". Thks.

Motion in sync with what you are seeing. If the motion is out of sync or 'wrong' in any way, then it could make things worse.

Another update.

I have managed to rewrite the arduino code so that it is modular and it now includes a comms module that works well with simtools (borrowed from here: http://www.xsimulator.net/community/marketplace/communicating-with-an-arduino-and-sim-tools.97/, written by @eaorobbie cheers). I still need to add in the code for the encoder as the tracking drifts quite a bit when being used with the game. But at least an encoder is mounted and attached, so that's half the battle. Ideally I would have attached the encoder to the shaft of the motor directly, but I don't have the option in this case, I expect the full scale to be different.

I also need another encoder inside the inner rig (for the roll motor), but for now this is a proof of concept (to myself mostly) and a way to test code without a massive cost upfront.

I did a quick test run with it connected to LFS to see if it was working.
Here is a video of the action:



Next I will try running it with MS Flight Simulator X and try to get full rotation happening.

Please keep in mind that this is a work in progress, and sorry about the length .

Explanation of the arduino code:

Everything has been split up into functions so that I can add or remove functionality as I go without having to recode too much, and without having to search the whole page. More will be added later but for now, this is the core program with basic functions.

To keep track of the position I have used a lowest common multiple unit which is common to each value:

Input from Simtools: 0-65535 (16 bit)
Input from rotary encoder: 0-599 (600 pulse per rev)
Output to stepper drivers: 0-3199 (200 steps per rev, but with 1/16th microstepping)

The lowest common multiple was calculated to be 4915200 (32 bit)

To keep track of everything internally, all values are converted into this global resolution which keeps them as integers. Unfortunately it also encodes everything as 'long'.

I have made provisions for other code changes, which are yet to be implemented. At the top of the code is type selection which will eventually run different versions of code as chosen by the user. There is only one for now.

The loop flows like this:

* Enable Steppers

* Check for new input
Convert input to LCM

* Decide on shortest path to setpoint (CW or CCW)

* Create an acceleration/deceleration profile for the trip (unimplemented, currently just using a fixed interval)

* Drive steppers based on profile
Update internal position
Constrain to 360 degrees (conditions for negative or greater than 360)


I will add an interrupt routine for the encoder to force update it's position, and override the existing internal values. This will only happen as the rig passes a pulse (600 ppr) and so shouldn't bog down the processor too much. But time will tell.

Explanation of each module:

* Enable steppers:

The stepper drivers need an enable signal from the arduino to pass current to the motors. I have reserved this space for when I add start up functionality (a start button or input from Simtools to begin, etc.). At the moment it is always enabled.

* Check for new input:

Read in the serial data from Simtools (16 bit) and convert it to the global LCM resolution.
The expected data is:
P*****~R*****~

* Decide on shortest path:

This part was tricky. I needed a way for the arduino to decide which way was the shortest path around a circle given a setpoint and current position. On a line, this is straightforward, but including the 0 point crossover was hard. I found 4 conditions which would give the answer in a simple way. I split the circle into quadrants (0-90, 90-180, 180-270, 270-0) and tested a move under each condition by hand until I found a pattern. I could go into more detail if anyone is interested, but diagrams would be needed.

* Create profile:

This was done in my last code (but it is rather messy) and would ramp up and ramp down when given a set of coordinates far from the set point. It was made to avoid losing steps due to acceleration, but I wanted the rig to be fast. This only works well when given a setpoint no where near the current position. The data from Simtools negates than by updating routinely, so there will rarely be a condition that is too far. And using encoders to keep the position on track will improve this. However the code is written to allow a variable step time if I add it back in later (something PID will probably go here).

* Drive stepper:

The speed of the steppers are decided by how much time to leave between each step. If time has passed greater than that of the step time (given by the above profile) then take half a step.
If last time was half a step then update the position as well.
The position must be within 0-360 degrees (but using the LCM global resolution). If it creeps above or below it is corrected here.

Repeat.

If anyone wants a more detail I am happy to share, but this is quite a lot for one post I think. Also if anyone has suggestions for a more optimised code, I'm all ears. I am not an expert by any means, and would like to learn more.

Looks good man

Have you seen these on YouTube

Yeah I've seen one just like that a few years back, painted red. I'm pretty sure it was called the Flymotion. I'm not going to lie, some of my inspiration came from their design . When I finally get up to it my full scale will be a bit different I hope.

I just signed up for this site but I know something like this is what I want to build. Time to plan!!

I am sick