vEx PWM Motor Response

[yoyodyne]

Last night I measured the VEX motor speed vs. PWM setting to build a linearization look-up table. I basically got the non-linear response I expected but what I didn't expect was that the maximum motor output actually occurs at around 220 for "forward" and 15 for "reverse". Has anyone else noticed that the motor output drops off slightly at PWM settings of 255 or 0 relative to 220 and 15 for instance? The attached plot shows the test results. The right and left robot motors were each set to a PWM value. After 500ms, the number of VEX encoder ticks over the next second was recorded. The program walked the PWM setting from 127 to 255 and then back down to 0 so there are a double set of points on the scatter plot from 127 to 255. There was some load on the motors from the driving the wheels via a chain and the shaft encoders themselves via a second chain but not a lot of load. Any additional experience in the area of linearizing the PWM to motor speed/power would be appreciated.

Thanks,

Greg

[Francis-134]

In some of our testing, we did notice that the Vex PWM does follow a graph similar to yours (so don't worry, you're not crazy). As far as trying to make a linear relationship, I would suggest trying to just not allow the controller send values to the motor if it falls within the deadband near 127 or at the nearly flat part of the curve near 220 and 15. If you want it even more accurate, you could take just the values described above and find a best fit line which you could then plug into your program.

[KenWittlief]

it would be interesting to see what the curves look like with more load on the motors - I think the curves would be far more linear and straighten out.

Controllers usually put out a voltage signal, and that normally corresponds to torque out of the motor (not speed)

so the voltage to speed curve becomes a function of load:

Voltage => torque (into a load) => speed

with no load (or a small load) applied the motor speeds up much easier.

this might also flatten the curve at the upper and lower ends ( the top and bottom 15 levels of the PWM commnand).

[yoyodyne]

Originally Posted by KenWittlief

it would be interesting to see what the curves look like with more load on the motors - I think the curves would be far more linear and straighten out.

Controllers usually put out a voltage signal, and that normally corresponds to torque out of the motor (not speed)

so the voltage to speed curve becomes a function of load:

Voltage => torque (into a load) => speed

with no load (or a small load) applied the motor speeds up much easier.

this might also flatten the curve at the upper and lower ends ( the top and bottom 15 levels of the PWM commnand).

Good point you bring out about voltage being more closely related to torque than speed. And that is why I made the post because it would not do much good to linearize against bad data in the first place. I don't really know how to set up a dynamometer easily. I could fairly easily measure stall torque as a function of the PWM setting just in the non-linear region toward full voltage and see if it is flat or not for starters. My real goal here is to use vEx as a teaching platform for FRC and I want the students to consider if it might make sense to linearize the motor response so that a % PWM change from a PID output came closer to corresponding to the same % change in the wheel speed, for instance. And that it is a better approach to deal with the motor response at the "motor driver" level than to tweak the PID parameter tuning (as an example) to account for the general slope of the more or less linear region of the motor response. Although the loop parameters will end up being driven by the dynamics of the platform anyway and maybe it makes no practical difference if the motor response whatever it is is thrown in the mix. It is also an excuse to use the EEPROM for the table although we need SIN/COS for other purposes.

Thanks,

Greg

[yoyodyne]

Well,

I tested the motors under load and I got more or less the same result. To load them I put the robot on a ramp that I covered with my wife's sticky yoga mat so the wheels would not break free and raised the angle until at a motor PWM setting of 255 the robot managed to move a couple of inches in 1 second. I then measured the how far the robot went (actually the shaft encoder ticks) down to a PWM value of 220 for 6 trials and the average performance (sum of encoder ticks) for each PWM value was basically equal so the motors do seem to top out in both speed and torque around a positive PWM setting of 215. So I am applying the following linearization lookup:

DESIRED -> OUTPUT
255 232
254 232
253 223
252 217
251 215
250 214
249 214
248 213
247 213
246 212
245 212
244 211
243 211
242 210
241 208
240 206
239 204
238 203
237 202
236 200
235 199
234 197
233 196
232 195
231 194
230 193
229 192
228 191
227 189
226 188
225 186
224 185
223 184
222 183
221 182
220 181
219 180
218 179
217 178
216 177
215 177
214 176
213 176
212 175
211 174
210 173
209 172
208 172
207 171
206 171
205 170
204 170
203 169
202 168
201 168
200 168
199 167
198 167
197 166
196 166
195 165
194 165
193 164
192 164
191 163
190 163
189 163
188 162
187 162
186 161
185 161
184 160
183 160
182 160
181 159
180 159
179 158
178 158
177 158
176 157
175 157
174 157
173 156
172 156
171 156
170 156
169 155
168 155
167 154
166 154
165 154
164 154
163 153
162 153
161 153
160 153
159 152
158 152
157 152
156 152
155 151
154 151
153 151
152 150
151 150
150 149
149 149
148 149
147 149
146 148
145 148
144 148
143 148
142 148
141 148
140 147
139 147
138 147
137 147
136 147
135 146
134 146
133 146
132 146
131 146
130 145
129 145
128 145
127 127

With this applied the resulting motor speed is as shown in R LIN, L LIN lines on the attached graph.

[gblake]

Like the other folks I got a big deadband (even though I seem to remember that VexLABS claimed that there is no deadband...) and the non-linear curves.

My RPMs went DOWN in a region near 255 and 0.

I folded the plot in the middle to try to overlay one curve (0-127) on the other (127-255). That is when I found out that 127-X doesn't have the same RPMs or slope as 127+X.

I suppose this shouldn't be a big surprise, but it causes a big headache if you try to autonomously drive straight by using shaft encoders to measure distance and toggling each motor between a set point and that set point +/-1 to even out distance traveled.

When I got to the end of the above paragraph I just couldn't bear the thought of using EasyC to write the code I needed. So... now I need to find the time to get familiar enough with the PIC to just use straight C compiled and loaded with the MPLab MCC18 compiler and the IFI loader.

Blake

[Gdeaver]

One note about driving the vex straight with encoders. There appears to be some latency with the encoder read block. Try toggling the order of the encoder reads. Read right encoder then left, take action, read left encode then right, take action. I was able to get consistent straight runs of 20 ft.

[yoyodyne]

Originally Posted by 1885.Blake

When I got to the end of the above paragraph I just couldn't bear the thought of using EasyC to write the code I needed. So... now I need to find the time to get familiar enough with the PIC to just use straight C compiled and loaded with the MPLab MCC18 compiler and the IFI loader.

Blake

Blake,

If you have MPLAB and the C18 compiler tools installed I can send you source for a differential (one wheel tracks the other) and individual (both wheels independently maintain the same speed) PID controllers. The only experience I have with EasyC is helping the VEX team members try to get around its many limitations and that takes a lot more creativity and effort in my opinion than just coding in C to begin with.

Greg

[gblake]

Originally Posted by Gdeaver

One note about driving the vex straight with encoders. There appears to be some latency with the encoder read block. Try toggling the order of the encoder reads. Read right encoder then left, take action, read left encode then right, take action. I was able to get consistent straight runs of 20 ft.

Thanks for the suggestion - I tried that - You or someone else gave me that hint before.

My machine would straighten itself each time its heading got off (detected by counting encoder tics); but the asymmetry in the CW and CCW motor response curve meant that it would slowly drift sideways each time it would slowly turn away from its intended heading and then more quickly compensate to return back to its intended heading.

Using EasyC to fix that (with proper timing of the sensor reads, filtering of the sensor data, accurate calcuation of position and heading, and feedback control of the entire system) was too much like sticking my finger in a light socket....

:-)

Blake

[gblake]

Originally Posted by yoyodyne

Blake,

If you have MPLAB and the C18 compiler tools installed I can send you source for a differential (one wheel tracks the other) and individual (both wheels independently maintain the same speed) PID controllers. The only experience I have with EasyC is helping the VEX team members try to get around its many limitations and that takes a lot more creativity and effort in my opinion than just coding in C to begin with. Greg

Sold! Send it to blake@verizon.net. Maybe in a few weeks (when I get a chance to do some coding again) I can add a bell or a whistle and send it back to you.

Thanks
Blake