Quote:
Originally Posted by apalrd
-Jim is actually an electrical engineer
|
Ah ha... now it all makes sense.
Mechanical engineers like to solve the controlling aspects of the drive and leave little for software to do... they are happy with just raw voltage input from the controls... and from this whatever non-intuitive issue arise it is left for the driver to get use to them and overcome them. This goes against the mentality of a software engineer which figures out intuitive solutions for all users to be able to pick up and use. If we cannot make it intuitive people will not buy our stuff.
Quote:
Originally Posted by apalrd
-We do like velocity controls as well, but we haven't implemented them since 2011. I think that would be a logical improvement to this system.
-That said, a simple PI controller to speed does not have a fast enough response time for drivetrain usage. We did this in 2011 and turned the gains WAY up for fast response, and oscillations weren't very good, but it worked.
-A better solution is one of the better speed control algorithms designed for shooter flywheel speed control (2012 was especially big on this, 2013 less). We ran a PI-FF algorithm with a feed forward equation (now we would just use a table), which is an improvement
|
Yup... I've been through the ringer of that as well as shown below... in 2011 we didn't know the value of linearization of the victors... which I guess is no longer an issue with the 888's. In 2012 we used the polynomial equation from Simbotics which worked out very well. In 2013 we applied the gain assist.... without gain assist the drive takes around 210 - 300 ms of latency. Using a closed loop solution brings that down to around 60ms. Using gain assist makes it virtually 0. This test shown here is a setpoint test using the drive like a turret... where each pixel column represents a 10ms iteration. The Magenta is the velocity line the green is the voltage, then Cyan is the encoder reading, and the yellow is PID error correct (which is not used in these tests).
