Prototype Pitch & Roll Full Rotation

Thanks for the explination @RacingMat !

Your method will work with stepper motors because they don’t use positional feedback. It won’t work as is on a motor that does though. When a motor with feedback experiences a flip in the data, it thinks you want to go to the extreme opposite position from where you already are. Therefore, it will reverse direction and run at the fastest speed possible until it reaches its target. But, it you test for a flip over condition every time information is updated from simtools, you can “catch” the error and deal with it appropriately. Below is the post I mentioned I would look for and is what I posted for another member a while back that was trying to deal with a flip over condition in the yaw axis. It, like you’re code, calculates the actual rate or amount of change in an axis even when a flip occurs.

Simtools does send positional information for roll, pitch, and yaw, but not in degrees. What it does send depends on the resolution you choose to output. So, if you choose to output in 12bit resolution for example, it will output a number of 0 to 4095, which corresponds with 0 to 360 degrees.

The code I wrote for my steppers already works in a similar fashion to your example @BlazinH but it monitors an internal position tracking register as opposed to an external position signal.

Which gives me an idea . I will modify the small scale prototype to hold an incremental encoder against the pitch motor gear and then test the feedback code to see if all works well. Hopefully this means I can also beef up speed. Until now I've been holding back because I lose too many steps with just internal tracking.

Thanks for the info @BlazinH regarding data output from Simtools. I will modify my code to accept this style of input. I will update my results when it's all finished. Better to test and modify small scale rather than later!

@dontcarefilmer , Sounds like a good idea to test an incremental encoder. That is probably your easiest way to do what you need to do. I like the double hall pot idea but it’s a little more complicated to hook up. And the microcontroller would need a mechanism to adjust a variable in the code to adjust the sync of the two phases among other things. But if you were to use motors and gearing similar to what I showed, it will not move anywhere once powered off. Therefore, as long as you position it where you want it to start up again when you power down, you wont have to home it at start up when using incremental encoders.

And I must say, I am assuming simtools will output an entire 0 to 360 degrees range but I have not done that myself. Since FSX has its own telemetry sdk, I wrote my own motion software to use with the simulator in the video above. Simtools development hadn’t even started yet either.

I’ve never had a project where I used steppers but I have always been concerned about skipping when used on a simulator. Apparently, some have done it though. I know your not talking about using them but I was wondering what a stepper does if needs to be reversed before it has completed all its current steps? Will it instantly reverse or must it finish its current steps first?

I can't speak for all the steppers or code written out there, but my prototype uses 1.8 degree per step motors (which gives 200 steps per revolution) driven by 1/16th stepper drivers (increasing the steps per revolution to 3200). In the beginning a destination is given, the loop code executes and it compares the desired destination to the actual location (as determined by internal tracking). If there is a difference it will determine the shortest path and execute a single step clockwise or counter clockwise. The tracking is updated and it compares itself again. Then it checks for new destination data. If the desired destination is still the same as before then no new path is calculated and it returns to the top of the loop. If the destination data changes then the whole process is recalculated.

So to answer your question @BlazinH, the stepper will finish a single step and check for new data before continuing. So no it won't finish the last instruction, but the most recent. It will almost instantly reverse. Within about 60 micro seconds with my settings at the moment.

I can upload the code if anyone is interested, but I'm a self taught programmer and so it might be tricky to follow .

nearly everyone here is self taught

Well that makes me feel better, thank you @bsft.

Thanks for sharing a little info about them with me! I look forward to your updates as progress continues.

OK, I know it's been a while but work and night classes have sucked the time right out of me. I have some updates but not as much as I'd like.

The code for my system is being rewritten from the ground up to be more modular and now includes the ability to communicate with Simtools. I think I needed to rewrite it because it had been added to and added to without a real plan as to how the whole thing would work. A lot of the individual code snippets worked fine, but any changes were too difficult to do.

I now have a 600 ppr optical encoder and have attached that to the pitch drive gear for feedback. This will be coded into the arduino soon as another module. Soon I should have it fully integrated with Simtools and show another demo.

It might be a bit early and off track, but I've gotten my oculus rift DK2, and it is a fantastic piece of equipment. I have just ordered an MSI GTX970 to drive it as the oculus demands some beefy graphics power. I feel pretty sick trying to run it at 30fps, but it's still fun.

When time permits I will update again, thanks for your patience.

good stuff man, hope it all goes together well. Even if you only run a screen off that GTX card, you will be stunned at the graphics.
I really need to destroy, er, I mean visit your place and have a go at the rift.
Dave.

I'm glad to hear you didn't give up on the project!

It's not dead yet, at least not until I work out the final budget. Then we will see

budget, yes price everything up and add 40%

40% huh. Yeah, I thought that might be the case. I didn't want to believe it. Maybe down the line I need to work on a backup plan, a cheaper mini version. Everything seems so much much cheaper over here in my make believe land, you should come and see, there is so much optimism.

BlazinH, what GPU do you use to control (3) 61" monitors? Thanks, Wayne

I’m using a gtx 770 atm. But my monitor’s resolutions are only 1920 x 1080 each so nothing special there. I run at 5760 x 1080 with all three together. I don’t use the bezel fix resolution because my monitors have a built in fix for this. They are actually Samsung DLP televisions that use laser intensity leds instead of a bulb. What is special about them though is DLP will do near perfect 3D and at native 1920 x 1080 @ 60htz with no ghosting of images. I can forget about nvidia’s lousy 3dTV play’s maximum 1280 x 720 resolution. If I wanted to use that resolution, I might as well be using a console instead of a computer. But unfortunately, there is no way to sync them together in order to use 3d on multiple units and so far I have not deduced a hack for this. Anyone have any ideas?

Btw, in the video of my rig above, I am using 3D so the image looks somewhat bad because of a double image, a bad camera angle, and just a bad cell phone camera.

Man, I thought I had it tough trying to set up the Rift. My troubles are nothing compared to what you described @BlazinH. That setup does sound really good though, and all of that from a single card, very nice.

Thanks! I would have thought it would taken a larger GPU (like a gtx780ti ot Titan) or multiple GPU's. Do you know the latency specs? I could not find on the net. Are you getting more than 85 fps on iracing?

I am curious, whats with the higher FPS needed or wanted on Iracing? I thought the human eye has trouble seeing more than 60 FPS anyway

Subject to much debate...90 miles per hour is about 130 feet per second. At 85 frames per second the 90 mile per hour car moves about 1.5 feet every frame. Think of it like a cartoon that we made when we were childen out of a deck of cards with the picture moving as we "fanned" the cards. The higher the FPS the less distance the car moves between frames.

Same or similar issue on the latency of the display. Some opt for high quality ones with 11 ms. Others say 30 ms is ok. The 20 ms difference is about 2.6 feet at 90 mph.

Probably less of an issue in games. But in real competition..many argue that the less "error" the better. Even with 11ms monitor and 85 fps, the error is theoretically more than 2 feet. This error reduces time to react to other cars in traffic. With 40 FPS and 30 ms monitors the delay could be nearly five feet at 90 mph....ten feet on a high speed oval like Daytona at 180 mph.

All this gets added to the ping time on the internet.

Like everything..there is no universal agreement..but typically iracers are Uber serious about best performance..so every little bit makes a difference. We would probably opt for much higher FPS than 85 but costs go up for the GPU quickly and there are diminishing returns.