Tutorial SMC3 Arduino 3DOF Motor Driver and Windows Utilities

Y

But I was still confused why Roll always on Axis 1, Pitch on Axis 2, Yaw on Axis 3, etc. Is this relate with the 'Generic 3D rotating' I am using? Sort of a template that is specific for 6DOF, maybe?

Perhaps, I need to use "Generic 2D advance" Axis plugin, so I can follow your approach?

With the command:
//#define REVERSE_MOTOR1 I can reverse the direction of motor1, How can i change motor direction for Motor 2 or Motor3 (motor output and hall sensor input) without do any rewiring.
Arduino Uno R3, SMC Utils V1.0
Thanks for any help! Kind regards, Piet

p.s. I found that the change in motor direction is automatically corrected in SimTools (V3) so no need to change it in SMC3

I am curious. I have uploaded the smc3 sketch to my Arduino. Then I tuned the motors with smc3ultility. How does this affect the sketch on the Arduino? I think not?
Do I need to changes the values from smc3utility in the sketch myself?

anyway I did change the sketch manual. But I could not find every value setting from smc3ultily in my smc3 sketch. Because of other names? Is there a conversion list so I don’t make mistakes?

whatever I did, it is working.. but I want to tweak my settings and am not sure this above.

I believe those 'saved values on the Utility' are stored in the ROM memory in the Arduino board.
Any tweaking of the SMC3 firmware (as motor's parameters) is only possible on the Utility app.

I did not read about this.
Ok, So they might overrule the sketch settings?

SMC3Utils automatically saves the engine settings in Arduino memory, sketch .smc3.ino you upload only once and you do all the settings in SMC3Utils which saves them autmatically

Hi SMC3-ers...
I would like to share my SMC3 code with an additional noise filter algorithm when the PWM is hunting the position. It works well on my BOSeTAMPER's 6-dof Rig.
https://www.xsimulator.net/community/threads/bosetamper-s-rotary-servo-6dof-build.19372/#post-255213

File attached. Please report any issue and hopefully help you all! It is much quite when it is idle... love it!

For your information, I am using Mode 1.

Thanks! So far no bug (yet)…

Hi,

I noticed that the I and D component of the PID regulator of SMC3 are not really working and implemented a fix.

The attached picture "I_not_working.png" shows the step response after configuring SMC3 v1.0 as a pure I regulator (Kp=0 and Kd=0). The I regulator doesn't do a thing, it just plays dead - even though I ramped Ki up to max. It's also not working at all on lower levels of Ki.
I expected the PWM signal to gradually change. The attached picture "I_fixed.png" shows the desired behavior.

The attached picture "D_not_working.png" shows the response of SMC3 v1.0 configured as a pure D regulator (Kp=0 and Ki=0) to a sine curve. The regulator hardly does anything, there's just some noise visible. Checking the code, I found a rather odd implementation of a D regulator. It's response is calculated based on the change in position, while it's usually based on change in error. So the noise we see in the regulator's output is just the noise it's getting on it's input.
I expected the regulator's answer to a sine wave to be the same wave but 180° degree phase shifted. The attached picture "D_fixed.png" shows the desired behavior.

I also attached a zip file containing arduino code with the I and D fixes I wrote. There are 2 versions.
1) Based of off vanilla SMC3 v1.0 as found on page 1 of this thread
2) Based of off Blame73's version of SMC3, for use with Cytron MD30C motor drivers

My changes are all within the 3 PID functions CalcMotor1PID(), CalcMotor2PID(), CalcMotor3PID() so they can be easily transferred to other SMC3 versions.
The current filtering/smoothing implementation for the D component via Ks could use some more sophistication. I was too lazy to do it, as I think I won't use the D component at all. In my experience, a PI regulator usually gets the job done pretty well. Really using the D component in addition to PI requires lots of tweaking while offering very little improvement in return.

Have I reinvented the wheel here? Is this a known issue thats already solved by other people? I wonder how the broken I regulator got overlooked for so long. I'm curious to read how you guys view the situation.

I have been working on the PID as well. My rig feels jittery when move in slow velocity during manual test move on the Utility software.
How does your rig feel when you use the original code? and what the different feel when you have the 'fixed code'? I am interested to learn.

I view it as a snafu. I have always thought that they were useless aka leave them at zero. On the other hand for cars its good enough. For planes its a bit jumpy. I have never seen a "sloped" line on PWM outside of your image but its always jumping all around.

I will do some testing and get back to this thread. My brain works better over a cup of morning coffee.

BTW: I did a diff from SMC3 v1.0 and found expected diffs in the CalcPID routines and that the version was set to 1.01.

Great! Looking forward to your testing report

Thanks for your replies.

I also used to drive my rig with SMC3 set as a pure P regulator (Ki=0 and Kd=0). If I increased Ki above 2 I got a lot of erratic movement on the motors that didn't make any sense. Similar with Kd.

Check out the attached picture "UnModdedPID_PureP_Motion.png". It was recorded using the vanilla SMC3 PID implementation with Ki=0 and Kd=0. To me it looks ok.
I also attached the picture "UnmoddedPID_PureP_StepResponse.png". Both the "pure" step response at the beginning as well as the manually softended step at the end show a permanent control deviation on the downward slope of the diagram (which shows my rig going up). The deviation remains constant at the end, where the desired position remains constant. This is typical for pure P regulators. Working against gravity, the motors would need more power to get to their desired position, but the pure P regulator is "too stupid" to realize that.

Now lets check out how my fixed regulator code works out. Instead of Kp=200, Ki=0 and Kd=0, I used Kp=150, Ki=50 and Kd=0. The attached picture "ModdedPID_PI_Motion.png" looks quite similar to the first version. If you take a closer look at the long down-slopes in the middle of the picture (where the rig is going up), you see that the deviation gets smaller the longer the movement lasts.
Finally, the attached picture "ModdedPID_PI_StepResponse" shows that there is no permanent control deviation anymore. This is expected of a (working) PI regulator.

But how does it feel?
I think my modded PID feels better than the original implementation. Doing slow up/downwards movement I used to feel a distinct torque ripple. It wasn't one smooth motion but like a fast series of mini-bumps that moved me around. I thought this was caused by imperfections on the motor gearing or cogging torque from the motor magnets. But I think this torque ripple is noticably reduced now that the regulator has a actually working I component. This makes sense as the I component of the regulator provides torque that doesn't change as wildly as the P component.
I don't want to oversell it, though. Maybe it's all just in my head. I'd be happy if other people gave it a try and reported their findings.

I was going to ask you if you have any cogging issue as slow speeds. It's a condition that seems to be an issue with PMDC motors. Let us know if you are able to eliminate it.

For my testing, I hooked up a laptop between my game computer and my rig. This process is loosely described in the general description on page 1 or 2. SMCUtils runs on the laptop and passes data from the game system to the Arduino. SimTools sends the data via UDP via an interface I set up for this purpose.

Using the built-in waveforms in SMCUtils is not the same as what happens in agame. I tried those first and everything looked fine. With this setup, I can observe the same displays but driven by the game instead. I’ve confirmed in my own mind that the integral term (Ki) is working appropriately. I can pull the motor into the correct position with low gain and a low PWMmin value. The Kd term is harder to test.

My first test was with Richard Burns Rally (RBR). This game is harsh and sharp so much so that with high gain, it tends to become unstable. Using the Ki term can provide a very stable result, even when set to relatively high values. So, if you want games like RBR to feel harsher than they already are, these two terms can accomplish that without instability.This is driving off the road. Kp = 300 Ki = 50 Kd = 10. Its not that sensitive to values.


The next test was with Microsoft Flight Simulator 2024. This is a very tough application to tune for. I use a sport plane Extra 330 LT which is very sensitive.

I don’t know what the issue is. If you watch the data coming out of the game, it’s smooth as silk possibly because I have filters applied.

Still, the position term needs to be set to a minimal value, like 200, to get reasonable performance. In this case, even minimal values (less than 10) for the integral or derivative terms cause undesirable results.


This should be smooth slow motion. The "ringing" s NOT comfortable like hit the estop uncomfortable.

The smoothest motion I can achieve is with the position term set to 200 and the other terms at 0.


You can see it is quite laggy but also very comforable ride unlike RBR.

So, unfortunately I don't see a net functional gain on the MSFS side.