The ROBOTC team is happy to announce the first public PREVIEW build of ROBOTC for Cortex and PIC with PID support (using integrated motor encoders). Sample programs on how to use PID are at the root of the VEX Cortex (VEX2) folder
NOTE: This build should be used only for testing the new PID functionality. This build is not stable for general use (i.e. classroom or competition) - This build should also only be used with the VEX Cortex System (not LEGO/PIC/Arduino)
* driveStraight - Currently enables two motors, but does not enable "synchronization".
* driveSynchronized - Currently enables two motors, but does not enable "synchronization".
* driveStraightToPosition - "Position" commands are not yet implemented in firmware.
* driveSynchronizedToPosition - "Position" commands are not yet implemented in firmware.
* moveMotorToPosition - "Position" commands are not yet implemented in firmware.
* mtrPid_Deadband - Command are not yet implemented in firmware.
* mtrPID_PowerLimit - Command are not yet implemented in firmware.
* mtrPID_Slop - Command are not yet implemented in firmware.
I’m going to be honest, I do not like this movement by RobotC. They are doing what I didn’t like about EasyC. They are dumbing down the programming experience by prefabricating the code, taking out the learning process. Please keep in mind that the idea behind VEX is learning how to be innovative and inventive while developing building and programming skills. Don’t become another EasyC.
Help with driving straight by matching the speed of left and right motors to an absolute number of encoder ticks per second.
Help with driving a pre-determined distance.
Perhaps help with moving an arm or lift system to a given position where the motors are using IMEs.
Allow for better slow speed control of the motors.
What it will not do
Allow use of a potentiometer to hold an arm at a given position.
Allow use of the original red quad encoders (that what I have been told).
By default, allow the motors to run at full speed and maintain PID control. There is some headroom to allow motors to be given more power if necessary to speed them up under load.
If you want to edit the PID parameters I recommend that you edit the PID settings in the top listbox which apply to the active program, this way the settings are stored with your code. If you edit system wide settings and share the PC with others or possibly move the code to a second PC then you may find that your code behaves differently if the defaults are different.
3.61, when using PID for the motors, is not compatible with my Smart motor library. When PID is running the actual motor command level is controlled by the underlying code rather than anything (other than 0) written to the motor] array. When the mtrPID_PowerLimit is functional I will update the SmartMotorLibrary to be compatible.
I have heard this comment from other coaches of competition teams and have mixed feelings about it. From what I can tell there will be nothing included that cannot be achieved with existing ROBOTC code, however, by being built into the virtual machine it will have better performance (by which I mean it will run faster and use less CPU time). I have an unreleased PID library and have planned for some time to write some tutorials before making it public, unfortunately I’ve just been too busy to do that so far. There are many customers for ROBOTC that do not build competition robots, I think the underlying goal for the built in PID is to try and remove the differences between motors due to build tolerances and the direction of rotation. This will allow the less experienced users to create simple drive forward type code without having to worry too much about why the robot does not drive straight due to these motor differences.
This a very good point and I had not thought of it that way. but I still think you lose the knowledge you would otherwise gain from programming it yourself, not to mention the elation of having something like that work after you spend a long time designing it. There are many things to take into consideration; I just hope this pattern doesn’t continue. I don’t mean stop trying to fix bugs or making more tools that we can work with, just don’t make it too simple because programming in the business world is not simplified. I mean this respectful as a avid user of the RobotC software.
As a programmer, I have to agree with you. However, I do not believe that this is going to be something so great that it will throw PID self-programming out the window. As James said, it appears to (right now) be only for speed control, and speed synchronization. I do not believe there is any planned support for the Gyroscopic Sensor, Potentiometer, or any sort of combination of IME’s and Gyro. Ultimately, I do believe that teams will use it, but the ones that really want their robot to be consistent will create their own PID loops using the Gyro along with the IME’s, and the Potentiometer, and possibly the Line Following Sensors and Ultrasonic Sensor, as well.
I originally held off working on my own PID code when I heard that ROBOTC would be releasing theirs. (I was busy at the time, and rather try out theirs for awhile instead of trying to debug my own, which I had problems with before.) However, once they started taking (much) longer than they had expected (they were working on other cool things), I went ahead and wrote some PID code. Our team tweaked it and got it working, and it was a great feeling when we got the robot driving around so consistently.
So, I do think that teams will use this instead of writing their own PID, but I also think it may even help as a segway for them into the world of more complex programming. Perhaps teams will write their own after seeing the benefits, but imperfectness of the built-in PID?
My only worry would be programmers who know they can use the RobotC code, so they won’t attempt anything more advanced.
I’ve seen this a lot with inexperienced programmers. The actual code for basic PID control is around 5 lines of C code. The calibration is the same in any implementation (although there are differences in unit scaling on some embedded platforms without hardware floating point). I see a lot of programmers in FRC (where there are PID classes available in all languages) try to stuff the stock ‘pure’ PID class into every situation possible, because they think it’s too difficult to write the code themselves. In many cases, individual controllers can use additional optimization to perform at their best, which the advanced teams will do, but many intermediate skill programmers won’t even attempt out of fear of the unknown.
Maybe tutorials on the basics of PID, and the algorithm behind it, would help.
To prove the 5-lines point, here are the 5 lines:
int error = setpoint - sensor;
p = error * kp
i += error * ki;
d = ((error_last - error) / dt) * kd;
out = limit_motor(p+i+d);
ROBOTC already has several built in functions that make life easy for you. These are low level functions and I could make the same argument about these as the built in PID. The ultrasonic sensor code is giving you a distance in units of your choice, there is no need to initiate the ping, use an interrupt to time the echo from objects and then calculate distance based on the elapsed time. This is not difficult code to write but no one is complaining about having this available. Same with the quad encoders and IMEs, ROBOTC could have just have provided some low level I2C calls and left it up to everyone to write the IME interface code but we have it easy and this happens behind the scenes, all we have to do is read the encoder count.
My point is that even with this functionality many students will still continue to struggle as they learn how to program. There are so many questions here on the basics of programming I doubt it will have much of an impact, those of you that know what you are doing will still be able to write far superior code.