Hi, apologies in advance for any mistakes, first post here!
My team is using the inertial sensor’s default built in PID. I adjusted the turn threshold and constant and it sort of worked (the bot used to shake around aimlessly) but it’s still quite slow compared to forward/backward movement (> 1 sec). Increasing the turn constant causes inaccurate turning, and then it takes forever for the repositioning. I know I should just try building my own PID, but I am having trouble getting into it. I was wondering if there was any way I could increase the turning speed just building on to the default inertial sensor code?
*our turn velocity is 150 rpm, using vexcode prov5
**does turn velocity even matter?
Every few runs the turns become extremely inaccurate and sometimes the driveFor blocks get skipped. The robot just executes all turns without going the full distances for forwards and backwards. Restarting the brain usually helps. I was wondering if anyone knew why this was happening (overheating?), and if they had any tips to fix it?
For some reason when we try to use driveFor with the default wait until finished = true, the wheels lock and the code doesn’t run. I was able to get past it by not waiting, but I was wondering if anyone could explain why this is happening?
Forwards/backwards code:
void driveForward (int direction, int distance) {
Drivetrain.setTurnConstant(8);
Drivetrain.setTurnThreshold(3);
if (direction == 1) {
Drivetrain.driveFor(fwd, distance*1.3, mm, false);
wait(distance*.002, sec);
} else {
Drivetrain.driveFor(reverse, distance*1.3, mm,false);
wait(distance*.002, sec);
}
}
Sorry if this is too much for one post, thank you for your time!
If you are using Visual Studio you can just check against the heading toward a desired degree
example:
desired_degree is the desired heading degree
tolerance is how much degree of error you want // I personally do 5 degrees
direction type is the way it turns
speed is speed
void GYRO(double desired_degree, double tolerance, direction::type dir, double speed){
while ( (desired_degeree + tolerance) < Inertial.heading(degrees) || Inertial.heading(degrees) < (desired_degree - tolerance) ){
//I'm not super familiar with drive train API so this might be wrong the main idea is that when its in //this looks the drive train is spinning
Drivetrain.spin(dir, speed, pct);
}
//Drive train should be stopped here
Drivetrain.stop(brake);
}
You call this function by calling GYRO(//than filling in the parameters inside)
example:
//start of program
inertial.calibrate();
wait(2,sec);
...
...
...
GYRO(180.0, 5.0, forward, 50)
wait(2, sec);
you will have to calibrate the inertial sensor before you start using your GYRO
I suggest looking up how to do a pre_auton
Sorry if there are errors I wrote this all out on my phone
The “inertial sensor” does not have any form of built in PID, it’s just a sensor returning an orientation.
The “smartdrive” class uses the value from the inertial sensor as part of a P controller (note, it’s not a PID controller) to perform turns. It’s deliberately very generic and simple, for best results you need to write your own code and tune to the specifics of your robot.
Its basically an acronym for different priorities within an odometry program.
More complex explanation
DYLAN: Dynamic Yield Locator and Navigation
D (Dynamic): This represents the algorithm’s ability to dynamically adapt to changing variables. The algorithm continuously processes incoming data to adjust its tracking and navigation strategies in real-time, ensuring efficient and accurate robotic movement.
Y (Yield): The “Yield” aspect of the acronym includes features that allow the robot to yield its path or speed in response to unexpected environmental conditions, enhancing safety and adaptability.
L (Locator): The “Locator” function refers to the algorithm’s capability to accurately identify its position, through tracking wheels and motor encoders.
A (and)
N (Navigation): The “Navigation” component encompasses the algorithm’s sophisticated path planning, obstacle avoidance, and route optimization functionalities.
Its not a specific algorithm per-se, and its a more private in-team teminology we use, but it essentially boils down to odometry. We just call it the DYLAN algorithm because those are the primary objectives of the program.
Interesting, but usually “and” isn’t included in acronyms, would it be more accurate to call it the DYLN method?? Also I couldn’t find anything online about it, is it a relatively new method?
Vowels are extrapolated from various words and stuff to make it easier to pronounce. (such as SONAR {SOund Navigation And Ranging}) Plus DYLAN makes for some fun puns regarding “taking” (that’s for you my publicist).
Also, DYLAN is most likely a niche VEX/teaching thing, as usually anything non-VEX would have a wikipedia article on it.
