3DoF G-Seat, All metal

Right now, I'm using an Arduino R3 Uno with an 8bit micro so it couldn't handle all of that. I also like the idea of absolute position sensors just because they know where they are on power up. I've been writing some firmware for one of my other 8 bit boards that should allow me to use SPI to talk to a sensor instead to get the position instead of reading the 10 bit ADC. With that I have some 18 bit position sensors (really only 16 bit accuracy at any decent read speed) that I could talk to. That would bring my degree per bit down to 0.00156°. Not quite as good as what you listed, but without all the overhead.
Those Broadcom chips you mentioned are very similar to the Melexis ones I have.

As far as SimTools goes, all it sees in my setup is a serial port. I've told it the packet format to send and the update rate. It just does a one way communication after that. You can configure for a lot of different interfaces besides serial too.

Yeah there’s a great argument for the simplicity of not requiring any homing routine when it starts up. Having had this discussion with you, I think that might be the way I go with mine!

Have you considered using Little GT2 style belts to drive the encoder instead of the cable? It looks like you've got about a 10 to 1 ratio on the pulleys you’ve designed. I’m sure you could get belts and gears to match that ratio, and it will be much more reliable. Because there is no load on the encoder, you could even 3D print the pulleys & tensioner and just buy a belt that will fit.

Those 18 bit sensors sound pretty neat! The AVAGO versions I’m using can only do 16 bit absolute output. Mind sharing with me what they are? That said, a 16 bit readout would be more than adequate for what you’re trying to do.

As far as read speeds go, SPI is pretty good. I think it’s up to 50 MHz clock speeds? Your bottleneck will be the arthritic R3 Uno. Given the amount of time and money you’ve spent on the mechanical bits of this rig you might want to consider upgrading to something a bit better. I use Teensy’s now almost exclusively because they’re reasonably priced, 32-bit arm based processors. The libraries for them is also better (less buggy and better optimised) in my opinion than the Arduino offering.

The two factors on getting motor PID loops to run smoothly in my experience is speed of the loop and the encoder resolution you get to match that speed. There’s no point in having a very high resolution encoder if the processor can’t keep up with the readout. You may as well just have a lower resolution encoder because you’re not getting the benefit of higher resolution.

It’s especially obvious when you’ve got motors that need to accelerate quickly and decelerate quickly (such as the case here). If the MCU readout is too slow, the overshoot behaviour gets worse and you have to start playing with I and D terms which can be painful and often doesn’t entirely fix the problem.

Really love what you doing man, I’m looking forward to seeing it all working!

The SPI from the chip on the Uno or Leonardo would be limited to 8 MHz, but that is still faster than it needs to be for what little data we are trying to transfer. With SMC3 on an Uno, the control loop for all 3 motors goes by at about 4 kHz, and the suggested settings for SimTools to interface with it only updates the 'target' position at 100 Hz. Increasing the resolution of the position feedback wouldn't affect the PID calculation speed in any meaningful way really.
I have an Uno R4 Minima that I've been thinking about writing some code for, but I've not yet had a need for the extra capabilities it offers over the 8bit stuff.

4 kHz for the entire program isn’t too bad, but I think across three (possibly 4 PID loops if you add yaw axis) your maximum PID calculation rate could only ever be 1 kHz at best. I usually use a 50% reduction for the best theoretical rate particularly if you are communicating with third-party sources over USB, UART, SPI etc which can cause large deviations in the loop time. So the best PID rate you could probably get is about 500 Hz. I’d venture that you want at least double that for this purpose. And the reason is below.

Okay, if XSimulator calculates the PID loops then ignore what comes after this sentence because it doesn’t apply. By this I mean the encoder data goes out via USB to XSimulator XSimulator calculates what the position and motor output should be and then sends this data back to your MCU.

If XSimulator outputs position data only to your controller (Uno) and the controller is in command of the PID loop, then the graphs below will most probably apply. In this scenario we’ll call XSimulator the motion generator and your Uno the follower. The graphs don’t show any real data by the way it’s just a visual representation of what the data might look like with two different time bases.

In the first graph all of the data is at 100 Hz. The black line is the target position provided by XSimulator. The red line is the output from the PID loop. For the purposes of these demonstration graphs the output is from 1 to -1.

In this graph you can see that the actual position varies around the target position because the PID controller is only calculating a new output at the same rate as the target position. I’d like to point out that this is in ideal circumstances because there is no guarantee that target position provided by XSimulator will align with the PID loop calculation unless you run an interrupt which triggers the PID loop calculation every time the target position updates.

In the second graph (the key is the same as above) the PID calculation is five times the target position update rate. You can see that the variance around the target position is much smaller. This is typical when the PID loop rate is higher than the target positions update rate.

In this control scheme with a higher PID update rate than the target rate, the PID loop is able to adjust the output based on the current actual position and rate of change making the motion much smoother.

Here are the files not as thumbnails so they're easier to see. I didn't check the correct box!

I understand what you are saying about the PID calculation rate, but thank you for the graphs for reference.

The microcontroller is calculating the PID, not Simtools. The 4 kHz rate I mentioned was for a complete program loop using SMC3 in the micro. So, it has read the feedback and done the calculations for all three motor outputs and checked for any new commands in each loop. I keep being amazed at just how much you can get out of these little micros.
The different firmware I'm writing for 4 outputs still achieves that 4 kHz loop rate using the internal ADC, I've not implemented any SPI communications to test that, but I will. Big thing is that SMC3 is using Arduinos AnalogRead function, which sits there and waits for the ADC conversion to complete. I changed it so that I'm off calculating all the PID stuff for a channel while the ADC is doing the conversion on the next. That way I can slow the ADC clock down a lot and get better accuracy out of it. Since I do believe I can so something similar with the SPI core, I have hopes that I can make that just as fast.