If I use moveVoltage() in PROS to control my motors, are there built in guards to make sure I don’t overvolt the motors? I don’t really want to cook every motor on my drive this year.
Vex has a limiter in it’s firmware on the motors, so you don’t need to worry about overvolting them.
Vex V5 Motors link:
“Advanced users can bypass the internal PID and take direct control with raw, unaltered PWM (pulse-width modulation) control. Raw control still has the same rpm limits, current limits, and voltage maximum that keep the motor’s performance identical.”
As @DVT7125 said, you don’t need to worry about damaging your motors, the firmware will limit voltage to 12v which the motors are designed to run at.
Fun, this (misleading) quote. I’ve been trying to get this corrected for years because of how misleading it is, but alas, here we are. Lets break it down
Advanced users can bypass the internal PID and take direct control with raw, unaltered PWM (pulse-width modulation) control.
Eh, not really. The motor will still scale our PWM inputs so that the maximum effective voltage sent to the motor is never greater than 12V. This means that when the battery voltage is say 13.5v and we command 100% voltage control, the duty cycle of the PWM in the motor will be less than 100% as the motor works to scale the 13.5v to 12v. A better way to say this would be that the user can manually command a voltage between -12v and 12v, subject to current limits, etc. (see below).
Raw control still has the same rpm limits, current limits, and voltage maximum
It is true that “Raw control” (called voltage control by most programming environments) has the same current limits and voltage maximum as velocity or position control methods. However, there is no artificial RPM limit imposed. This means that an unloaded motor running at 12v under voltage control will typically spin at 15% or so above the rated velocity. For example, I have seen 200rpm motors commanded to 12v free spin at about 230RPM, sometimes higher or lower. So it is definitely possible (and usable in practice) to make a motor spin faster using voltage control than would otherwise be possible using velocity control.
4 Likes
Well thank you for pointing this out! I did notice that my robot indeed went faster when using voltage, but I thought I was going crazy. Funny how that is still not fixed.
Along with “PID is internally calculated at a 10 millisecond rate.” on the website, if you use VexCode,
It have a 20ms delay, even though I would think it should be 10.
It’s also the same way in the vscode extention when generated using the clawbot competition template
(Also the different formatting in the code is funny.)
But if using the V5 competition template (yes it is 2 different things, how intuitive)
It will do it every 5ms…
(I use 0.125ms, but I have no idea what the polling rate is, or if I am limited by 10ms pid even when using voltage.)
Nothing to do with VEXcode. The motor has a PID loop running in its firmware that runs every 10mS.
4 Likes
So does that mean that all things sent to the motor are limited every 10ms?
Like in a loop for the Left and right motors, even if i did wait 0.125, would it be limited by 10ms by the PID? Would it get around the 10ms rate by using voltage? Is even having a wait for the loop needed because you will always be limited by the PID?
messages to the motor can go out at best every 5mS. You will only see status from the motor change every 10mS.
The fastest the motor will update internal values, even voltage, is every 10mS.
Well, you need the loop delay in VEXcode for other reasons, allowing other threads some time etc. also if using the D term, you need a loop delay otherwise error difference is likely to always be 0 or very small.
2 Likes
It’s also worth noting that aside from the 5ms and 10ms figures for the Motor, the Controller over vexnet has its own update rate of 25ms. So, controller values won’t change more often than that in most scenarios.
However, for latency reasons you will probably want to attempt to update your drive loop faster than 25ms. Think about it this way. With a 25ms loop and the controller updating at 25ms, you have no idea when in that 25ms cycle the controller will update, only that it will update at some point in that time range. So, say the controller pushes new values to the brain right after our drive loop has updated, say 1ms afterward. Then, we wait 24ms more until the next run of the drive control loop and we finally update our drive motor powers with the new controller values. In this scenario we have a latency of ~24ms. Now, say we switch our drive loop to 5ms. In that scenario, the most latency we could ever have is probably about 4-5ms. Now, is a 20ms a whole lot on human timescales? Maybe not, but this is something to think about.
There are lots of weird quirks like this in V5, especially if your source of truth is only the documentation in the VEX knowledge base. @jpearman 's posts here on the forum are a really great source of information and I’ve learned tons from him over the years here, but it’s a bit disorganized. I’ve been thinking for a while about starting a page on the BLRS wiki to document as many of these things as possible, but school has always gotten in the way. Perhaps after I graduate/after worlds this year…
4 Likes
Just one consideration, typical human hand-eye coordination response time is usually around 200ms. Folks practiced and developing “twitch” reactions get closer to 150’ish milliseconds, but in most cases, you’re not going to see a lot of improvement.
So while a 5ms loop time may update more quickly, it’s going to eat up more processor time and possibly starve other operations that could have effects on the system. I’d obviously defer to Vex folks like James, but 20ms is a very reasonable update for driver-in-the-loop operations. Autonomous may arguably have some benefit to a faster loop time, and since you’re not concerned about controller latency, etc., there could be some argument for a 5ms loop if the motor loop is 10ms (Nyquist, etc. etc.). Will you really see an effect from that level of timing difference? Not knowing all the particulars of the V5 processor and the underlying handling, I’m going to go on a reasonable limb and say probably not in most cases.
1 Like
Yes, but that’s not the end of the story. Try using a mouse cursor with a 200ms latency added to it, and you’ll definitely feel it. It’s even been demonstrated that lower latency is noticeable even at much smaller margins. For example, players using 120 and 240Hz monitors (1 frame every 8 or 4ms) have been demonstrated to have a significant advantage over players with 60Hz monitors (1 frame every 16ms) in various video games. Latency is about more than just reaction time, it’s about how easily predictable a system is for the driver.
Of course, as we both noted 20ms is really not all that much, especially when the controller is already adding up to 25ms of its own latency. So once you start getting into the low single digit ms delays, like 5 ms, concerns about things like scheduler parameters like quantum, minimum thread run time, etc. should be considered a lot more carefully. If I had to pick a number, I’d honestly say 10ms is probably a nice middle ground, and it also happens to line up with the rate at which VEXos gives user code new sensor, etc. data.
P.S. @jpearman in regards to the VexCode scheduler, what are some of the critical parameters that programmers should be aware of, especially for time sensitive code? I know that the VexCode scheduler is cooperative rather than preemptive
(like FreeRTOS in PROS), so I’d guess quantum wouldn’t be applicable. But say, is there a minimum task runtime in VexCode? Or if I have 10 small trivial tasks that all yield appropriately is it feasible for them to all run within 1ms?
2 Likes
Well, honestly don’t have time or energy to get into this much today. But during initial dev of the scheduler I used to stress test it using a program that maxed out all tasks and events. Each task was more or less like this.
int
UserTestTask3() {
static int counter = 0;
int task = 2;
lcd.foregroundColor(ClrRed);
while(1) {
vexDisplayStringAt( 10+60*(task/10), 20+(task%10)*20, "%05d", counter++);
if(counter > 99999)
counter = 0;
TASK_DELAY
}
}
where TASK_DELAY was
#define TASK_DELAY vtask::sleep(1);
(ignore the vtask class and other non-standard APIs, these proceeded the final names and were abandoned)
80 tasks would be started and then approximately 50 user triggered events.
I don’t believe each task ran with a 1mS interval, but pretty sure it was far less than 10.
Output looked like this.
6 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.