How granular should I design my encoder feed to EKF3 to be? One pulse per 0.1" vehicle traveled? One pulse per 1"?
On my rover with wheelchair motors, I could put a standard 12 PPR magnetic encoder on the (3.5k rpm) shaft of the motor, producing about 40k pulses per second, x 2 motors = 80k interrupts per second. Will this be too many for my Pixhawk 4? The encoder accuracy into EKF3 would be very high, each pulse would correspond to about 0.1" traveled by the vehicle.
Alternately I could put the encoder on the shaft and build an optical encoder at 4 ppr, bringing the encoder frequency down to about 13k per side, 26k total, with one pulse per .3".
Alternatively I could put a 20ppr encoder on the output of the wheelchair motor, which turns much more slowly, about 140 rpm. This would produce 2.8k pulses per second per side, 5.6k Hz total, corresponding to about 1.4 inches per pulse.
I would first try whichever is easier and see if it works. 80k interrupts per second is a lot and internally AP sends the data no faster than 20hz (for now) to the EKF so most of those pulses will be grouped together but the overall accuracy remains.
Basically I don’t know what the upper limit is on how many interrupts the flight controller can accept but cm level accuracy (which is the lower number you’re suggesting) seems like a reasonable number.
I’m getting ready to buy some 900 PPR encoders for my wheelchair robot. Have you got yours to work yet?
My electric wheelchair motors have a gear ratio of ~32:1 and the diameter of my wheels are 10in, so that would mean one pulse would be .001in of travel, and at a speed of 2m/s, you’d have a pulse every 12.7us. That seems awfully high, but like Randy said, if it’s grouping the pulses maybe it’s not that big of a deal.
I made a post about the setup I’m thinking about here, I’d be interested to hear what yours looks like.
I haven’t implemented encoders yet. I ended up not putting encoders on the shafts of the wheelchair motors. There’s a bit of slop in the chain between the wheelchair motor and the drive axle in my setup, actually, about 4-5 revolutions of the wheelchair motor. I think that could end up confusing to the autopilot. Putting the encoders on the powered shaft itself (i.e., down below the deck) puts them in the way of lots of debris and I don’t think that’s a good solution. My current thinking is that the roller chain itself is the best place to put an encoder (i.e. have an optical encoder that looks through the links and gets one pulse per link on the chain, which will give me about 40 ppr on the main wheel, on the order of 1 pulse per inch). I’m using #40 roller chain.
That’s quite the setup Christopher, very exciting!
I like the idea of counting links, but wouldn’t the chain slop still an issue? It might be tight in one direction, but if you reverse the wheel rotation the slack switches sides. Maybe you could throw an idler sprocket in there to keep things nice and snug, just a thought. Then you could put the encoder on the back of the gear motor. Just my two cents. Again, awesome setup!
I went ahead and order the encoders I mentioned above, I’ll let you know how it turns out.
I’m leaning strongly to using ABS sensors on reluctor rings attached to the axles. I’m also using a chain drive wheelchair motor configuration and have some slop in the chain still. I will be managing that with an idler soon. With wheel slip in my terrain being a given, having ultra high resolution doesn’t seem like a benefit. ABS sensors are dirt cheap and readily available, and they are proven in very harsh environments.
Those are indeed interesting.
I am only now starting to move from R/C (to prove the chassis) to ArduRover, so it may be ‘a minute’ before I get to outfitting odometry. I’m expecting the wheel rotation sensors to be confirmational - the wheel is turning - more than an odometer. Optical flow seems a bit more well suited to that I’d think - and I am hoping that (optical) odometry will be a fallback to RTK. Almost entirely conjecture on my part though. Just have to see how things play out once I start actually testing in real life.