Yes exactly. Outside of those limits, it should do nothing. It would seem the Danfoss was designed for use with like a potentiometer type of installation (analog signal) for flow control. Being 1/2 DC allows you flow in two directions without needing a corresponding negative supply.
Anyway, i hope someone at least tries the type of input signal the valve was designed for.
I am using an IBT2 to control the steering on an 8330 with Danfoss. I have 12v on the Udc pin, and the pwm signals from the arduino sets the Us. 6V steers straight ahead, 9V to the left and 3V to the right. I have some pics JD 8230 hydraulic steering . Its not a clean setup but it has been working nice on my one field test cultivating. @theGtknerd i noticed while i was originally setting up that with 1 hz on gps it was all over the place, but now at 10hz its smooth. Any chance that could be an issue for you? I have been using v3.9 with the coffeetrac button ino. I think that with the code written like i have it below that it seems to be working fine on my bench test setup but no actual field experience yet. I am a total arduino beginner so if anything in this coding seems wrong please let me know.
Autosteer PID
void motorDrive(void)
{
// Used with Cytron MD30C Driver
// Steering Motor
// Dir + PWM Signal
if (aogSettings.CytronDriver)
{
pwmDisplay = pwmDrive;
//fast set the direction accordingly (this is pin DIR1_RL_ENABLE, port D, 4)
if (pwmDrive >= 0) bitSet(PORTD, 4); //set the correct direction
else
{
bitClear(PORTD, 4);
pwmDrive = -1 * pwmDrive;
}
//write out the 0 to 255 value
analogWrite(PWM1_LPWM, pwmDrive);
}
else
{ // Danfoss: PWM 25% On = Left Position max (below Valve=Center)
// Danfoss: PWM 50% On = Center Position
// Danfoss: PWM 75% On = Right Position max (above Valve=Center)
// Used with IBT 2 Driver for Danfoss
// Dir1 connected to BOTH enables
// PWM Left + PWM Right Signal
pwmDrive = pwmDrive / 4;
pwmDrive = pwmDrive + 128; // add Center Pos.
pwmDisplay = pwmDrive;
analogWrite(PWM1_LPWM, pwmDrive), // apply varying voltage to the Usignal valve pin
digitalWrite(PWM2_RPWM, HIGH); // apply 100% DC current to Udc
}
}
danfoss should indeed do nothing when outside the 0.25-0.75 Udc on the Us pin (safety for ground or supply shorts) .
Udc should also be stabilized (not directly from battery/alternator).
When Udc is been fed with stable 12V, one can use a industry standard 0-10V analog signal to control Us.
So, after a hectic summer, and a still busy winter, I will post an update.
We got the Danfoss valve to work using the code I posted on Github. My friend (who owns the tractor) also spoke directly with a Danfoss representative, who tested a PVE valve on the test bench. The Danfoss tech guy recommended using PWM 4KHZ or higher. This said, our Danfoss valve worked fine on the default PWM speed. Well, that is after we had the PID set up properly. The end result was that we had to turn up the minimum PWM quite a bit, and keep fairly low values in the PID. Sorry, I don’t have all those values with me. However, this only worked with old versions of AOG, which brings me to:
We wanted to use the newest AOG (several reasons, I forget what all). When I discovered the ESP32 project that doesn’t use steer characteristics info coming from AOG, but can be set in the built in webUI, we switched to the ESP32. So far we are happy with the performance, and I am now working toward a PCB to plug the ESP32 into as our setup looks crummy, and we experience occasional disconnects. It’s not surprising, given the state of wires in our setup.
There’s some small changes I made to the ESP32 code, and when I have proved the code/PCB a bit, I will see about making a GitHub repository to share the PCB, code and BOM. Until next time, gotta run…
Interesting explanation!
This one also very “visual”…
Oh PID. Before AOG I built one of those 2 wheeled balancing robots, worked really well and of course used the full pid control. Then I started dong autosteer - and realized that most of what i learned for normal PID did not apply. I have yet to figure out why.
Looking at some other commercial systems they use multiple P, PI, PD loops to compensate for all the problems a second order control system like steering brings. It seems the more “perfect” you try to make autosteer - the worse it works. I find it all a bit frustrating that it is more art then theory.
It’s become my understanding that PID is only suitable when all the system processes & reactions remain predictable without any random external influences. It seems to work pretty good for adjusting the autosteer wheel angle but when I tried to use it as a cruise control for our sprayer then there’s too much that changes such as ground resistance and load weight, things like that.
Especially the derivative term.
In the last 7 years I have setup around 12 vacuum pumps with a VFD and vacuum transducer. The only math that works for vacuum pumps is PID. People have tried anything from gain/bias to linear mapping, but it ultimately is not successful or low resolution. I admit a lot of my success in PID and controlling vacuum with pump speed was good fortune and not necessarily because I’m that good.
And then I decided to control my house temperature with PID. The coal boiler feeds in coal according to the PID, based on the feedback from the room temperature. So I learned some more about the whys and wherefores to PID. In this case I had to throttle the update speed, because heat transferred to water and then transferred to radiant heat is slow by nature. So sometimes PID calculation speed has to be matched to the process.
I also found that some ABB motor drives (VFD) have a PID loop for the sensor, and then they have a PID loop for the motor speed. These drives are a nightmare to setup. Basically you set the motor speed PID as tight as you can without tripping error codes, and then tune the sensor loop to control and stabilize the process.
One thing that took me a while to wrap my head around is that PID has a setpoint, and the feedback is used to create an error value. So lets say you want the wheels pointing to 50° and they are at 55° :
error = 55-50 (5)
P = 10
P * error (50)
And that’s only the tip of the iceberg. There’s I and D yet… When this all gets tuned properly, it is a charming system.
In some cases you need to limit the max Integral, usually when the generator/pump/valve is high capacity and the controlled system is small or responds quickly. The Derivative is to control fast changes on the feedback, or abrupt changes to values in the PID. The Derivative counteracts the Proportional, helping smooth the output.
I’m also working as control software engineer mainly for process industry.
PI/PID is not always always the best solution, but this is frequently the one with the best performance with limited complexity.
To improve the PID behavior, they are some tricks to be used :
Performant measurement : A PID control relies heavily on the measurement, especially when the derivative action is used. This link explains it quite well:
https://controlguru.com/measurement-noise-degrades-derivative-action/
Thats also why the derivative term is not used so often in process industry.
I see promising work in progress on other topics of the forum 
Search for linearity between control and error : You should have quite linear reaction from controller output through the practical use range of the controller. If you have not something quite linear, your parameter choice will be more complicated and will use compromise to fit all the range at best.
For example : Calculation before the PID on measurement or after the controller can make the controller action more linear.
This allows the controller to compare apple vs apple.
Probably already done in the in AOG software to give a correct angle (i did not check this)
Use of cascade controller : the use of cascade controller is way to improve controller lineary and to reject fast disturbance with a faster controller when the final controller is quite slow (because his process is slow). This not always necessary or doable. We usually need the fast controller to be faster than the slow one. The more difference in speed the more gain.
This is already done in the steering wheel - wheel angle controller and this seems to work very well according to user comments.
The slow final process is the GPS position measurement that gives angle setpoint to the fast angle controller.
Limit dead time : In a pid controller, we need to limit any dead time (relative to the process reaction time). A bigger dead time leads to less aggressive control and slower stable response.
When this is done, the PID controller is usually very good at rejecting random disturbances against simplier control methods.
In this case I had to throttle the update speed, because heat transferred to water and then transferred to radiant heat is slow by nature. So sometimes PID calculation speed has to be matched to the process.
I don’t agree with this one. You can always control a slow process with a very fast calculation interval without any problem. It’s only a waste of computing resources.
You can search for fast (but approximate) perturbation rejection (with P action) thus need fast calculation interval and have a slow process that needs long time to settle (so long integration time and slow integration). Your integral action calculation should take into account the calculation interval. A change in calculation interval should not have any impact on your control parameter (if your calculation interval is fast enough, at least 10 times faster than your process and constant).
I agree with you guimchevalier.
The big picture of this post was not to figure out all the fine details of PID. Rather, I was trying to understand why PID wasn’t being used in AOG. As I see it, some setups work better with PID and some do not. Interestingly, the last post by BrianT seems to indicate there is already an Integral in AOG.
If I ever have the time, I would like to dig into AOG and see how Brian’s doing the steering math. Not that I feel that I can improve it, but for interests sake.
Time for another video!! I’m working on a very different concept on centering the pivot axle using a cascaded stanley algorithm plus integral/derivative loop that moves the steer point left or right to line up the pivot point on the guidance line - which in the end is what we want. The trick is, the pivot point doesn’t steer, and that is where the fun begins to remove the cross track error without wandering or oscillating.