|
Re: VEX inputs
ChrisH & GDeaver,
I would appreciate seeing your control algorithms/equations or your code that uses shaft encoders to supply feedback for controlling your Vex bots paths.
I am dabbling with the same thing right now and mine is both wobbly and biased.
Right now I attempting to have both sides maintain 50_tick / 100_msec speeds and I am using 5:1 gearing to make the the encoder count 450 ticks for each revolution of the drive motor.
Because I am think I am getting different response characteristics from my motor(s) when I compare driving them CW vs driving them CCW (see below), I think I am ultimately up against writing some semi-complicated trig equations/approximations. Maybe I am thinking too hard...
I am adjusting the bot's speed by just incrementing/decrementing the EasyC command sent to each motor depending on whether that motor's encoder counted more or less than 50 ticks during a 100 msec EasyC "wait"; and depending on whether that motor is already slower or faster than the other motor.
The slow reads of the encoders Gdeaver hypothesized could be one problem I face.
Another problem might be that (contrary to what I read on in the VexLAbs fora) the motors react differently to commands that are identical except for direction (i.e. sending 127+70 produces a different RPM magnitude from a motor than sending 127-70). That means that starting my left and right motors at values that will produce (nearly) identical RPMs is a matter of holding your tongue in the right place; and furthermore, that incrementing the input to the CW one will produce a different change in output (for that one) than does decrementing the input to the otherwise symmetrical CCW motor on the other side of the bot.
I admit, the assertions in the paragraph above are generalizations from measurements I took on ONE motor while the bot was up on blocks.
I graphed the motor transfer function results (encoder ticks over ten consecutive 100 msec intervals) vs input value) in Excel if anyone wants to compare my results with any other measurements.
Does anyone else have any motor measurements to share? In addition to wanting to combine the fun of implementing my own ideas with not re-inventing too many wheels (see request above for sample algorithms), I am curious if I got unlucky with the one motor I measured; or if there is a pattern we should measure carefully and report in an appropriate FVC thread.
Blake
PS: Should we transfer this discussion to the Vex Shaft Encoder Kit thread???
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
|