My bad, you are right about that they were meaning when it comes to them asking about VEXCode vs VEXCode Pro. I kinda misread that as OP was talking about PROS vs VEXCode.
If the spin command has no headroom then it simply goes full power and does not have any capability to adapt to deviations. That is why the spin command is slower, to allocate the headroom. I have tested myself and found that a 200 RPM motor will spin around 210 RPM±1 on voltage. This is a significant amount, especially for a drivetrain where competitive teams have negligible friction on their wheels, if built correctly.
You are correct, however, that the secondary reason sometimes is incorrect. This is known in the robotics industry as “PID on PID” and is sometimes implemented in many motion control algorithms like a robotic arm, where you have a main positional PID algorithm for moving an arm to a position controlling joints that have a velocity PID. It’s not uncommon for velocity PID’s and position PID’s to be used, however you are correct that it’s not necessary for, like, pure pursuit on a drivetrain.
On the PROS website you listed here: API Home | PROS for V5
It lists “Okapilib” and provides the following page: OkapiLib Index Page | OkapiLib A PROS library for programming VEX robots
And if you click “Tutorials” for okapilib, it goes to the ugly code, that of course isn’t maintained.
As for PROS 4 documentation… It looks worse to be honest: Home » Tutorials » Walkthrough Tutorials » Programming the Clawbot | PROS for V5
This doesn’t really look like a tutorial, despite being one of the primary tutorials on the PROS page.
Tutorials don’t list any examples to a degree that is fundamentally understood for newcomers:
https://purduesigbots.github.io/pros-doxygen-docs/adi.html
This is not really a valid example:
void initialize() {
encoder = adi_encoder_init(QUAD_TOP_PORT, QUAD_BOTTOM_PORT, false);
}However this is promising:
https://purduesigbots.github.io/pros-doxygen-docs/group__cpp-adi.html
and a step in the right direction, but the example seems un-necessarily verbose:
#define POTENTIOMETER_PORT 1
#define POTENTIOMETER_TYPE pros::E_ADI_POT_EDR
void opcontrol() {
pros::ADIPotentiometer potentiometer (POTENTIOMETER_PORT, POTENTIOMETER_TYPE);
while (true) {
// Get the potentiometer angle
std::cout << "Angle: " << potnetiometer.get_angle();
pros::delay(10);
}
}To put it bluntly, tutorials should assume that individuals have at least some C knowledge, but should try to understand that the vast majority of individuals have very little prior knowledge to C++. Basically, there is a threshold where teaching is more important than merely being “right.”
And frankly, I have always seen the PROS library be oddly scattered all over the place, with a degree of fragmentation that is hard to just “Get Started” for newcomers. No “Next” that nudges newcomers on what to do next. It’s just pages that abruptly end.
