Last active 22 hours ago
@tabor473 Exactly. It's a unit conversion from encoder units to motor units. The example you gave I find is the best way to get everything to click.
I'll add one more point to this. Yes, Kp is a unit conversion. However, it's important to remember that there may be various desirable values of Kp, depending on preferred behavior: fast convergence, less oscillation, less jerk.
Can someone please explain to me what P loops and PID loops are, and what difference exists between them? Any help will be appreciated.
A P Loop is a programmed Proportional controller. It uses the error between a desired and current value to modify a parameter through the mutiplication with a constant 'Kp' that is then added to the parameter to help reach that value. In the case of a fly wheel, you try to reach a certain angular velocity, by modifying the 'power' the motors get.
An I controller is an integral controller. It takes the previous integral sum from the last loop iteration and adds it to the current loops (error times time passed since the last loop iteration) (dt). A constant 'Ki' is then used to modify the controlling parameter through mutiplication with the total error and then added to the parameter.
A D controller is a differential controller, that takes the previous error Minus the current error, divided by the time passed between those two errors to derive the rate of change. The controlling parameter is than changed by multiplying a constant 'Kd' to the rate of change and that product to the parameter.
Think of K as a parameter that converts the answer from each controller into a value in the order of magnitude of the controlling variable.
A P Loop is therefore simply a PID loop without an I or D controller.
I apologize. It's been a while since I've competed!
Pretty neat stuff.
This entire year is exceeding my expectations. The possibilities these changes open up towards robot design and pure sensor processing power is insane. With processing of sensor information now allowed outside of the V5 brain, you could conceivably allow a micro controller determine the exact position the robot has on the field, and then relay that information via a single connection back to the cortex. That would allow the micro-controller to handle a vision sensor, multiple sonars, etc. all in one...
Not to mention hardware filtering...
There's been a lot of disgruntled posts regarding changes to the competition structure.
Let's talk about something I'm sure we can all agree on: the new VEX U changes allowing unlimited machined, printed, punched, etc. parts is amazing!
Drill it out, the ratchet doesn't have to turn on the axle, it simply needs to keep something else from spinning the wrong way!
Time to be controversial: BO1 has one very serious upside, and if you take the utmost advantage of it, it will reward you like nothing else will.
BO1 guarantees that if you pick the team that is best suited to your mutual needs, you will play every elimination match with them.
That means that this is the year where scouting early, often, and enthusiastically will help you more than ever before. There is no need to compromise with an under-performing 3rd pick. All you need to focus on is who you can crush with.
I'd also like to add that this switch brings the added benefit of allowing more teams, especially newcomers, to gain experience fighting out alliance matches. Even intermediate teams benefit as a result of the increase in alliances, by giving more teams the right to pick alliance members.
@Leeoon I'm not aware of any debugging steps.
I'd assume so, but it's the only one I have, so I wouldn't know.
I'm not using a code, I've only plugged it into the cortex, and plugged the cortex into the computer, so I view the sensor data tab in RobotC.
Debugging steps is just anything you've tried to pinpoint the error.
I'd do what 224x suggested, both with the cortex you're currently using, as well as a different cortex. If neither helps you, then its likely something is broken with the sensor (whatever it is).
Worth trying as well: attach a different sensor (ie. quadrature, potentiometer etc.) to the same port and observe the behavior.
Leon, what debugging steps have you tried?
Does this problem occur with just the specific sonar sensor you are using?
Have you tried a code that ONLY takes sonar measurements in order to ensure that it's not a coding error?
Can you link your code?