Budget Compact 6DOF Universal VR Flight / Racing rig - MSFS, SMC3, FlyPT, Transducers, Controls

The problem is that the drivers (Cytron, Sabertooth) and the arduino are also negative connected so the ground between motors, Arduinos and hall sensors (even the PC) are always shared

@Ronan Design can you please post your schematic of the whole controller cabinet once again? I can't find it anymore. I still have the problem that my browser sometimes doesn't display embedded pictures. So make sure you insert is as thumbnail. Thanks

Thanks, yes, that's the schematic. It does not include the LCD voltmeter/ammeter devices, which are not essential. But just in case, here's how they are wired:

They are rated up to 100V/10A, which should mean 1000W, so they should be good for 41A @24V which is more than I need.

Ah, thanks @noorbeast for posting the schematic, again. The original post still looks like this in my browser. It doesn't like big pictures embedded in the posts.


@Ronan Design The problem with the sensors is the "daisy chain" of the power and ground wires to the sensors. The red and black wires all go to the first Arduino while the signals (yellow and blue wires) go to different boards.

You should run three seperate wires to each sensor and connect +5V and ground to the same Arduino where the signal goes. (this is called "star grounding") The best cable would be a shielded twisted pair. (+5V and signal as twisted pair and ground on the shield). If you don't have such a cable twisting all three wires should also work as long as they don't run close to the motor cables.

Be careful, the fact that 100V * 10A is 1000W doesn't mean that you can run 41A @ 24V through it. Power at the shunt resistor is proportional to the square of the current, no matter what the voltage (at the supply or motor) is. So 40A means 16 times the rated power @ 10A!

But don't worry. I think the average current doesn't exceed 10A and the shunt can handle very short pulses of higher currents.

Exactly my thoughts. I have found precisely the cables you described lying around. those are old high-grade audio cables with a twisted pair inside and shield outside, so I use the shield as ground and the pair as +5V and return signal and solder them directly to individual Arduino boards. I also found some ferrite cores I'll clip on, and I can also solder capacitors between ground and signal which supposedly can help with HF noise. I need to figure out if I have suitable ones and where to put them - at the Arduino side or directly on the sensors.

I think this movie might be interesting

I have rewired the sensors with the audio cables, and connected each voltage and ground to its respective Arduino board. It did help a lot. I now see noise levels in line with what I had on my 2DOF. I need to do more testing because I did see a couple of spikes, but overall it's a big improvement. I also added a ferrite clamp close tot he sensor on each cable. I could still add capacitors to see if I can get rid of more noise.

I swapped the direction of every second motor in the SMC3 firmware to make it work correctly in the FlyPT. Now the motors seem to move correctly and consistently with the 3D Viewer with all the motions I model in FlyPT mover. Now I need to do thorough testing to make sure no motor runaways can happen because that would ruin the day very fast when the motor arms and top platform are connected. I'm considering adding stop switches but that's a lot of switches and contacts and wires (adding potential points of failure), and they weren't triggered even once on my 2DOF in 3 years. Once I'm reasonably sure the system works properly, I will add the motor arms and top platform, test all motions, then add gas struts and weight on top, then when it all works, add the rest of the structure.

Good to hear that the new sensor cables helped.

About stop switches, a rule of thump is to install them only in the case that a runaway would cause catastrophic failure. I think with rotary actuators that doesn't happen. It could cause violent shaking of the rig but that unlikely event can be handled with a kill switch (E-stop button), I think.

Additionally - airplane rule: Put all your eggs in one basket after making sure you have a really good basket. I mean, double check your cables and connectors. Secure everything with cable straps, protection tubing and so on. Make sure nothing becomes loose to avoid a runaway occurs in the first place instead of thinking about how to handle it.

I added 0.1uF (104) capacitors to all 6 sensors and also added ferrite clips around all cables on both ends now. I have no severe problems now, however, some noise is still present. The motors are not visibly twitching but they are crackling a bit.

This is the data from the sensor when the motor is under power:



And this is the same sensor when I turn the AC power off, so motors are powered down. The signal is definitely much clearer.



I also have some motor twitching at extreme positions. What's interesting is that it only happens when I hit the "clip" line, so maybe SMC3 is at fault here. If I go below the line and the signal is not clipped, the twitching disappears.



I've read on some post that the SMC3 code can be modified with taking the running average of the last 10 reading, which should smooth out the signal, but there was no code there and I can't figure out how to piggyback the GetFeedback function of SMC3 for the running average.

I think the idea is that if the incoming signal is outside of set bounds the clipping should just quietly limit the signal, so it doesn't go beyond range and it shouldn't break hard. But the implementation is probably flawed and what you said may still kick in beyond clipping range. Or it may even be an intended behaviour of CMS3Tools so this braking could be tested. I god a mild cold, but when I'm better I will fabricate the motor arms and start testing the platform movement.

Meanwhile some progress.
I assembled the top platform:




And attached the seat base:


I hope the thick plywood will hold the weight and the G forces. I think it should. I can reinforce it if it flexes too much, but I actually think a tiny bit of flex is a good thing so the platform is not too jarring.

Try PWMmin=5 to quiet the engines
I confirm that I too have fitted 0.1uF (104) capacitors to my 2DOF motors and the signal is almost perfectly clean, the motors have become silent.
Noorbeast , maybe pin this post at the beginning of the forum many people have problems with noisy signal from potentiometers or hall sensors and the way is easy and cheap

All right, I now have another problem. I connected FlyPT Mover and fed the square wave to heave, so all 6 motors are working together. When the amplitude is about a half of the range (total of 45 degrees or smaller, approximately) it's all fine. However when I get to around 70% or more of the range (70 to 90 degrees total rotation range) one of the boards goes into cutoff mode, despite the range definitely below the cutoff zone.

It doesn't happen when I go slowly, it's all fine throughout the range. Only fast movements do this, and the position of the arm that freezes is not within the cutoff zone.

What's really strange is that my PSU that the computer (but not the rig!!!) is connected to goes into protection mode for a second, as if the power is dipped or something. The PSU and the rig are on different power outlets, though they likely sit on the same circuit. I suspect somehow the motors (that have no load at this time, just 3d-printed dummy motor arms!) suck so much power the rest of the power is dipping and the Arduinos glitch somehow. It's definitely the "DisableMotors" function that gets triggered because it shuts down the relay I have set up for that purpose for one of the boards. Any board can glitch at random, it's not always the same one, though one is more prone to this than others.

Any ideas about what's happening and how to avoid this? A sudden full heave motion is very plausible, and it would just shut off the entire rig. I need to sort it out before I connect the top platform...

Feed a sine wave (think square wave is something that will not give out in reality).
However, an airplane to change its dive or roll angle takes some time.
I think you are testing your 6DOF too hard

You said it only happens when moving fast and the position where the motor stops is outside the normal travel range? That would mean the cutout is happening while the motors decellerate. I mean instead of braking actively at least one of the motors looses torque and coasts to a stop exceeding the travel range, right?

If that is true then it could be the reverse energy problem I warned about early. I suggest you monitor the motor supply voltage. You need a meter that reacts fast and can show short divergences. An oscilloscope would be ideal but an analogue meter or a multimeter with bar graph can also do the job.

Watch the voltage. You probably see a small droop when accelerating and a small overshot when decellerating. The faster the movement the higher the under/overshot. This is the energy that recirculates between the power supply caps and the mechanical inertia. If the voltage gets too low or too high the PSU goes into protection mode.

Adding rectifiers between the PSUs and the motor drivers should stop the PSU from faulting out but the voltage at the driver still overshoots causing the driver to go into overvoltage protection. That cuts cutrrent and torque so the motor coasts to stop.

A possible cure is to add a battery or a very large capacitor to buffer the fluctuations. Overshoot can also be cured with a shunt regulator. It bleeds excess power to resistors whenever a voltage threshold is exceeded. I think Cytron offers a shunt regulator board.

Not exactly. It does happen when moving fast and wide - but the motor arms do not exceed the travel range at any time - and the stopped position ends up around 80% of the travel range, below clip or cutoff points. My PSUs do not go into protection mode - they keep working. I do have rectifiers between PSUs and the motor drivers - everything stays cool, I feel no detectable heat either at the motor driver heatsinks or the rectifiers. There clearly is an induced power spike in the 120V house circuit, because I can hear my PCs UPS triggers a few seconds of protection mode during the event. I assume it's a consumption spike or noise of some kind. I will try another outlet and another power bar, because my power bar has protection circuits and they could be interfering maybe?

I have SMCTools set as 255 for both for PWMMax and PWMRev because I assume I will need all the power I can get from the motors.