Not sure, but just wanted to point out that the quad encoder doesn’t have to measure the rotation of the flywheel itself…it can be geared down and still be used reliably since the ratio will be known based on the gears/sprockets you choose. Therefore you should be able to make encoders work no matter what.
It would still be nice to know the maximum speed at which they are accurate though! Hopefully someone will test it…I will for sure when I have time, but I’m guessing by then someone will have beaten me to it.
Hoping to measure the end wheel due to any bits of sloppy gears. Not sure how big of a difference it makes.
We’ve had grinding and dust affect these puppies in the past. Simple to clean (as long as you can get them out). Faster RPM’s will probably make this happen faster/more often I think.
1500rpm on the encoder is about a 9KHz interrupt rate (1500/60 * 360), an interrupt every 111uS. That should be easy if the underlying code is correctly written, perhaps I can fire up the oscilloscope and test (not as easy as it used to be, wish I had my own scope but they are expensive).
Edit:
Yes, I edited this now I’m home and reread it, forgot to convert rpm to rps. It should be easy to handle an encoder running at 1500rpm.
The main problem will be missing interrupts, this can occur if the speed is too fast or if the phase of the two outputs has an error that becomes significant as the speed rises. For a launcher application it may be better to use one of the two quad encoder signals, ie. use it without the direction information, we just care about speed, we know we are going forwards. This will reduce interrupt rate by 2, we could also use only one edge of the signal to give a further reduction by 2, I can do this in ConVEX but not sure about ROBOTC etc.
I did some tests It’s been a while and the results are mixed.
I made a simple system using one motor geared with 7:1 ratio to an encoder, this runs the encoder at about 750rpm.
Here is the first scope shot.
Yellow and blue traces are the two outputs from the encoder. Pink and green traces show when the code is interrupted and how long it needs to service that interrupt. I’m using ConVEX and can easily modify the library to show this.
Good news is that it takes very little time to service the interrupt, about 600nS (although not apparent from this scope capture, I measured that with a different timebase).
Bad news is that the two outputs from the encoder are not aligned very well in my encoder, notice how the rising edge of the yellow trace is very close to the falling edge on the blue trace. It also moves around, we are seeing tolerances on the encoder wheel and variations in how it moves through the sensors. This scope trace is probably worse case, sometimes it is better. The above showed an offset of somewhere around 40uS.
Here’s a closer look, not quite as bad here, about 80uS. We would like it to be around 180uS at this speed.
So I’m thinking 1500rpm will be OK, at least with ConVEX, probably wouldn’t want to go much beyond that.
Here’s what also worries me about using the red plastic encoders like that:
Consider 1500 Rev per minute for a 2 minute match = 3000 revs if you keep the ball launcher motors going all the time (If you don’t keep them going all the time, then you’ll have to allow more time for them to get up to speed between launches. Maybe that’s okay???).
8 matches in a day results in 24000 revs.
To put that into some perspective:
Assume 4 inch wheels on a robot’s drive chassis, so the robot would travel roughly 1 foot per rev.
Field length is 12 feet. A round trip on a field is 24 feet. Consider 24000 revs is equal to driving your robot back and forth across a field 1000 times.
Assuming a robot velocity of about 2 ft/sec, that means 12 seconds for a round trip times 1000 trips = 12000 seconds, or the equivalent of 3.3 non-stop hours of driving around on a field. Think the red plastic encoders can handle that? I’m not sure they can and I hate the idea of using IMEs.
Probably not, my setup was very crude (run out of parts, didn’t disassemble last years projects yet) but the poor little encoder was vibrating quite badly even at 15 revs per second.
But IMEs are great
Either way, I’m not sure yet we have good enough control of the VEX motors to maintain a constant speed with high gearing. Lots of new experiments this year.
I can’t find the thread but somebody somewhere had reported their motors were overheating and tripping their PTCs after about 50 seconds of continuous operation. I’m not sure they were using the internal turbo gearing or the high speed gearing, but I’m interested to hear the results if anyone should do a test like that and confirm. Perhaps gearing up internally will cause some overheating issues if the ball shooters are run continuously???
I can see that being an issue this year. Teams should stock up on air dusters. They have coolant in them and can be sprayed on motors between rounds to keep them cool.
I wish I could believe that. I’ve heard so many complaints about them. It seems you couldn’t use them in SkyRise if you wanted to run wires all the way to the top of your robot (the I2C lines weren’t originally intended for > 4 foot-ish runs). So that leaves short wire runs, like to the chassis motors, but the durn IMEs are reportedly susceptible to electrostatic discharge, which drive wheels in the wintertime can generate in shocking quantities. Maybe IMEs will be useful this year for the ball shooters, but. then again. perhaps we will uncover some other, new IME failure mode to dash our hopes and dreams. :rolleyes:
That’s an ominous statement. Would you mind elaborating a little on that? I think there are a lot of forum members already planning PID controlled ball shooters, so… uh… what are the potential problems?
The PID people code to is typically managing the positional control on robots, not speed control. Doing velocity control is a bit harder to tune but the same principles apply. How far off are you from target, and adjust. You are just working with a derivative in time for speed control.
So getting to a harmonic frequency of speed control to apply the I and D elements may whack that motor pretty good and you want upside too. But you are looking to keep max speed most likely to shoot far.
So a P on the speed controller is probably what we will see more often than not and tuning down the faster one to the slower one. But slowing down may not be that advantageous anyway since you will probably not reach the desired target.
Slightly different question. The I2C I thought reported back at best every 4-8ms depending upon how many you have in the daisy chain. It’s a nice set of bits coming back to the Cortex per device and they all report back in a line.
So will we have enough data points to control the motor speed on the IME? You can only change the speed via a new PWM signal every 20ms.
Is there any notion of when that 20ms interval is for a motor within the code so the timers can be not too far from the next PWM signal to the motor will be sent?
Lots, I’m not going to go negative before doing my own series of experiments. Build quality, as usual, will also play a huge part in determining how successful this can be. It’s one thing to have a square shaft in a simple bearing block when it only rotates 1 or 2 rotations every second, when that goes up to 25 revs then we have a whole new set of issues.
I played with velocity PID a bit last year as part of the linear lift project, but that was with the opposite gearing, most of the PID we have used in VEX in the past had 1:1 or lower gearing, now we are going the other way, small change in motor speed will produce bug change in output shaft speed.
It depends on the firmware, ROBOTC will poll as fast as possible but will round robin all the encoders on the bus. So with 1 IME you can get data every 1-2mS, with 4 IMEs, each one will be polled every 4 to 8mS (it all depends on message length, when the reply comes back and where that falls in relationship to the 1mS timer tick). EasyC polls much less often (the last time I measured this). ConVEX (surprise, surprise) has much more flexibility but in general will try and poll an IME every 1mS. ConVEX (being open source) can be modified to give priority to a particular IME, perhaps the shooter IME would be polled every 2mS and others every 10mS.
As always, motors in ports 1 and 10 can be programmed to work with a PID loop much better than those in ports 2 through 9. It is possible to synchronize the PID loop with the motor message that goes to the master processor, but after that everything is running asynchronously.
As the load on the free spinning shooter, when not loaded with balls, is pretty constant, I’m not sure PID (in the traditional sense) will even be needed but I’m not going to throw all my ideas on how to do this out just yet.
It’s been a while and the results are mixed.
