Tutorial SMC3 Arduino 3DOF Motor Driver and Windows Utilities

I have not yet started to play with SMC3. After my first MSFS helicopter ride on my DR-P3, I realized that the backlash and cogging was totally unacceptable. So of course I began modding it. I hope to be done within the next couple of weeks. I read that there is a manual for SCM3 but haven't looked for it yet. I may find some time to play with it this week to get an idea of what all the settings are. I get the right hand column controls the elements of the movement graph but have no idea what the other settings are. I just fly helicopters, ultralights, and small GA aircraft. So it's critical that it be smooth, but also sensitive to small nuanced movements. Is it possible that this isn't the right software to meet my needs?

@Joe Cortexian
Thank you for your work.Does your post refer to the PID implementation of the original SMC3 or to my implementation?

@noorbeast

Yes, also thank you for your suggestions. Also, sorry for not answering.

You are correct in that the square wave response of my PI regulator setup shows overshoot. On the other hand, with the "motion" waveform there is no overshoot.
I've tried various combinations of Kp and Ki and, while I found combinations with less or no overshoot with the square wave, they also followed the "motion" waveform with much more lag.

I use my rig playing flight simulator games in VR, so the "motion" waveform is pretty close to my real application, while a square wave is way different. Also, I consider low lag as quite important, especially in VR. For those two reasons I stick to a regulator configuration that overshoots a little when facing a square wave.

After all, having a fast regulator without overshoot is something like the holy grail of regulators. From my experience, in order to even hope to achieve something like this, a full fledged PID regulator, with well adjusted D component, and good, low lag filtering of the input, would be required. The filtering part is currently missing. Maybe something like a gliding, weighted average kind of thing. But honestly, I don't see myself implementing that. There's other stuff I'd like to do that promises more fun or improvement.

About the Max Limits: Yes, I set a bad example setting max limits to 0 here. I have non-zero values for my other 2 motors, but for some reason the motor I used for those screenshots irregularly, but repeatedly, crossed the max limit and was then shut off by SMC3 mid game. Quite immersion breaking and quite a hassle to resolve each time. The clipping limits are the same for all my motors and I didn't want to let them clip sooner. So I reduced Max Limits for the motor that kept turning off. It "solved" the issue without creating new ones, so I run with it. I know it's kind of risky and nothing to recommend. I know I should have looked for the real reasons the motor crossed the max limits. But meanwhile, this "solution" has reached the "if it works, don't touch it" stage.

Regarding your recent implementation:
For tracking sharp, rapid movements—such as those in boxing games or rally racing—it should offer noticeable improvements. For smoother, more gradual movements, like those in a flight simulator, the difference may not be significant.

Mechanical ringing could definitely contribute to the roughness I’m seeing in the flight simulator. If the rig is oscillating or overshooting due to resonance (especially with those gradual inputs), it might amplify the issue beyond what the PID control and 10ms updates can handle smoothly. Since sharp movements in boxing or racing likely demand quick damping, the ringing might not be as noticeable there, but the slower, sustained adjustments in a flight sim could let it show through.

Do you have experience with a flight simulator?

@Joe Cortexian
I have only experience with flight simulators and have not yet tried racing games with my rig.

I'm sorry for asking again but I am still not 100% sure if the pictures in your post from 31st of March show the result of the original SMC3 PID implementation or my fixed regulator code.

You are very unspecific when you talk about how the regulator code will affect certain games. The original SMC3 code for the I and D regulators behave very differently from my textbook-like approach. Thats my sugar-coated way of saying "the orignal SMC3 regulator code is broken, regarding the I and D component". Also, I and D regulator components behave very differently from each other. When you talk about what makes sense for what kind of games, I think it is essential to differntiate between those 4 things.


I can see how a working D component of a regulator can improve the regulator's response to sharp, rapid movements. However, I demonstrated that the orignal D regulator code is not working in the sense how a D regulator is traditionally defined. Like I've written, the orignal SMC3 implementation is based on the difference between the current position and the position that was measured in the cycle before.
If you take a look at how D regulator normally works, you'll find that it's based on the difference between the current positional error and the positional error that was measured in the cycle before.
That small difference in wording makes a huge difference in how the regulator acts.
A D regulator is sending strong command signals if the positional error (where the motor should be vs. where it actually is) suddenly gets larger or smaller. So a working D component helps the rig keep up with sharp, rapid movements. On flight simulators, with smooth slow movements, the D component shouldn't do much. In fact, as the input signal has noise, even a working D regulator component might do more harm than good.

It's a different story with the I component. Again, I have shown that the orignal SMC3 regulator code is broken with regard to the I component. Only the P component works. My working I component provides torque that doesn't fluctuate as wildly as the P component. This could provide a smoother experience in flight simulators than the pure P regulator, that most SMC3 users seem to use, can offer. On the flip side, a I regulator component won't do much for a rally simulator with its harsh, sudden movements.

To summarize: the fixed D component helps make car sims harsher while the fixed I component helps make flight sims smoother.

All the plots are with your modified code. I will double check when it starts raining again. I have seen inconsistent behavior in MSFS.

With my old code, a P value around 200 gave me reasonably smooth performance in the flight simulator. Higher values, even for racing, often led to instability—specifically, oscillations.

Your modified code lets me push P higher (up to 300) when paired with an I value of 50. This combination of a higher P and an I component creates a much “harsher” racing simulation. A better term might be more responsive. It delivers faster accelerations without noticeable oscillation.

I’d really like to address the flight oscillation issue. It could just be a matter of tuning the parameters. Could you clarify the specific values you’ve set for P, I, and D in your tests? What is the style of your rig? YMMV

I returned to the starting line with my tuning and managed to achieve fantastic results! I wholeheartedly support this adjustment—it’s a game-changer. Not that I ever doubted the assertion that the earlier software was defective.

The breakthrough came from cranking D up enough to make an impact. I’d been too timid about tweaking D. I went back to tuning on the sine wave, where I’d been overly cautious before due to wrestling with the faulty software.

Ultimately, I landed on P=450, I=30, and D=20. Those numbers won’t suit everyone, but I’d wager the proportions are close to universal. In other words. For my setup, bumping either I or D up by 10 triggers undesirable behavior.

I’ll update my original post with caveats for anyone who doesn’t arrive at this solution on their own.

Thank you for your effort.

Hello everyone, I'm new here. I'm having trouble despite checking what was said and the instructions over and over again. Motor1 is working properly, meaning the motor receives commands when I turn the potentiometer to the right or left, but your motor2 potentiometer doesn't work at all on the left side and rotates very fast on the right side. Do you think there could be a problem?

When I swapped the drivers, the problem completely changed places. The problem on the right moved to the left.

I installed smc3 published by Sebastian2 , can confirm that the movement of the motor is certainly smoother, below are my settings for the wheelchair 24V motors I use in my 6DOF. Increasing the Kd parameter caused strong oscillation of the whole 6DOF.
Overall I like the software, ideally there would be a soft start version.

@Attyla.pl
I edited my initial post about my PID fix and added a a modified version of Klaus Schmidinger's SMC3 fork with Soft Start.

@Joe Cortexian
I wouldn't have predicted that a working I component allows you to use higher Kp values. I had to tune PID regulators in a professional context a couple of times. There, a increasing one parameter (like Ki) usually meant that another parameter (like Kp) needed a reduction in order to avoid instability. But like you said, YMMV.

I am running a 3DOF with heave, with rotary motors.

With my revised PID code I'm currently running Kp=170, Ki=30 and Kd=0. You can find the results for the motion, sine and square waveforms attached to this post.
At first I had Kp=150, Ki=50 and Kd=0. This looked good while the "motion" waveform was running, but the sine wave hat some artifacts where the rig would be highest up. With Kp=170, Ki=30 and Kd=0 those issues went away while "motion" still looked good.

I also tried some different Kd values. However, I couldn't get smooth movement with the sine or "motion" wave with Kd values different than 0. As soon as I use Kd values like 10 or 20, motion that should be smooth (input-wise) gets translated to rough seat movement. The yellow PWM line in SMC3util also gets rough.

You really get smooth motion with non-zero Kd values? What Ks value for filtering are you using? Could you post a SMC3util screenshot showing how the "motion", sine and square waveform looks with your rig running?

Not sure what I'm doing wrong, but I'm getting a ton of compilation errors:

C:\Users\Baz\Desktop\SMC3\SMC3_v2.1_SoftStart_Sebastian2.ino:319:16: error: variable or field 'InitMotor' declared void
void InitMotor(MotorData &m, int Index)
^~~~~~~~~
C:\Users\Baz\Desktop\SMC3\SMC3_v2.1_SoftStart_Sebastian2.ino:319:16: error: 'MotorData' was not declared in this scope
C:\Users\Baz\Desktop\SMC3\SMC3_v2.1_SoftStart_Sebastian2.ino:319:27: error: 'm' was not declared in this scope
void InitMotor(MotorData &m, int Index)
^
C:\Users\Baz\Desktop\SMC3\SMC3_v2.1_SoftStart_Sebastian2.ino:319:30: error: expected primary-expression before 'int'
void InitMotor(MotorData &m, int Index)
^~~
C:\Users\Baz\Desktop\SMC3\SMC3_v2.1_SoftStart_Sebastian2.ino:457:13: error: variable or field 'SetPwm' declared void
void SetPwm(MotorData &m, int Pwm)
^~~~~~~~~

Etc.......

Nevermind, apparently you can't have more than one file in the smc3 folder.