I’m having difficulty trying to tune a velocity PID loop, and I’ve come to the conclusion that part of my problem is that the PWM outputs aren’t changing at a predictable time relative to the PID sample time. They’re not even changing at the same rate.
Is there a way to detect when the User and Master CPUs have exchanged their information? Or does EasyC even use the same “every 26.2 ms” scheme that the IFI default code has? So much is hidden behind the scenes and I don’t know how to peek behind the curtain.
EasyC is easy for simple stuff, but I’m apparently fighting it when I want to try more advanced coding. I can’t believe that I have to jump through so many hoops to do things that aren’t predefined, and I have to think I’m just failing to see the “right” way.
The easiest way to fix this is use a timer to execute the PID every 26ms. This is what I’ve done for PIDs with mechanisms and steering. I was having trouble with tuning also without the timer.
We are also planning to post a new version of easyC with a logging feature in the terminal window so you can format PrintToScreen in CSV format and use excel to graph data.
There are a few ways of solving the problem. There are 6 predefined timers that you can read that update automatically. Actually, they run off the same timer interrupt - a 1ms clock. So if it works out, you can only do integrating when the timers reach, for example, a 20ms multiple. You can also request periodic timer interrupts where easyC (WPILib) will call a function of yours with interrupts disabled at each interval. This has all the usual ISR writing caveats.
You can also find out when data exachanges between the master and user processor by looking at the packet number and waiting for a change. This is done by calling:
unsigned char GetPacketNumber(void);
This function gets the incrementing sequence number that changes every 26ms. In your own loop, you can notice the packet number change, and take whatever actions you need to. This is probably better to keep the PWM updates and your calculations in sync.
Do one of these work for you? If not let me know and maybe something could be added.
First, we perform the PID calculations based on a timer every 26 ms instead of the 20 ms we had been using.
Second, and more important, we switched from trying to control the wheel velocity and went to a position-based PID scheme instead. Now the control parameter is the desired robot location (and orientation) instead of the desired speed (and turn rate). The PID constants take care of making the velocity what it needs to be in order to get to the right location without overshooting. For manual driving, the joystick input constantly sets the desired position in front or in back of the current location, and when that point is set farther away, the robot travels faster.
