Motor / Encoder Adventures

I finally got stable outputs from the encoders on the IG32’s. It was nothing to do with the encoders, it was all interference picked up from the drive power lines. So that means a major re-design of the way I do motor performance measurement, since I need to do the ADC and encoder counting physically closer to the source, rather than back in the rover body. Dang it all.

That means a major re-wire, but it will be worth it. In the end I’ll also have to run FOUR more Atmel MCU’s; two ATTiny84’s for the front wheels, and two AT328’s for the mid-and rear wheels (one per side), and then tying this all together with a single AT328 as an I2C master. It does make a bit more sense and matches better with what I’ve done on the Rover 5 platform, which means the DRV chip is basically just handed an instruction to execute; ie “go that direction x units’ or ‘turn this much’.

The DRV chip then takes care of monitoring the progress and setting the PWM levels sent to the motor driver PCB’s, so I can also bake in some anti-slip and anti-stall code fairly easily. I had to do this same idea on the Rover 5 to keep the tracks from coming off.

Anyway, below is the data from a set of tests on an IG32 motor. It’s rated at 24v but run here at 25.2v (from a 6s LiPO battery), and being driven through a Cytron MD10C driver PCB. Actually, all three motors on one side were running for this test, although I only measured one of them.

The encoder outputs are pulled to +Vcc by a pair of 1K resistors (as per the datasheet), and then I watch just one of them in an interrupt. From that interrupt I also measure the other encoder, so I can deduce the direction, rather than use two interrupts per motor. This was an idea posted on the Arduino forums by user johnmchilton and it really makes more sense to do it this way.

The very small glitch around PWM = 187 is interesting; it’s probably something to do with how the MD10C converts the input into an output, or how the Arduino / Atmel is doing it’s PWM output – but I’m not going to worry about it at all.

The overall linearity of the system is really surprising; I was expecting more of an ‘S’ shape, with a slower build-up to a mostly-linear mid section, and then a tail off at the top where there would be essentially no difference between the to ~10% of the PWM values.

The top speed here is showing 205 cm/sec; or ~2 m/s, which is about 50x faster than Curiosity, which I think runs around 4cm/sec. Since this is a no-load test with the wheels were up in the air on that side, the real top speed can’t be determined yet. I think the original design notes were for a 1.6 m/s top end, so it’s likely I’ll be in the right area. Given the way that the rocker-bogie behaves it’s not like I’m going to be burning over rough terrain at walking speed anyway… for the rough sections it’s easier to control at much slower speeds.

The speed is dictated by the wheel size and shaft RPM, which in this case are 120mm Wild Thumper wheels and the apparent RPM’s from the encoder data was about 326 at PWM=255. That’s faster than the rated 265 RPM; likely due to driving it at 25.2v on a fresh battery. I reversed the math to see if at ~24v it would be closer, but it still yields about 310 RPM.

My math could be ‘off by one’ here, as I was using 7 clicks per rev, as found by turning the wheel by hand and counting the encoders off. Each test gave ~133 clicks, which for a 19:1 gear train would be 7 encoders per rev. BUT I could be counting the start/stop click twice in my thinking, and it’s really 6 encoder clicks per rev. That would actually mean it’s faster, which again doesn’t make sense. So maybe I’m not counting the last click (on average)… and it’s really 152 clicks per rev (8 at the winding)… ahhhggg. It doesn’t really matter, since the difference is only 10% in the speed, and I’m probably right; it’s probably 7, because of the 19:1 ratio and the fact that all the tests gave around 133 to 135 clicks per rev.

Once it’s on it’s wheels again the way to get useful data will be to run some actual ground tests and measure the distances/times. I suspect I’ll see more of that ‘S’ curve, where there will be a longer dead area at the bottom of the curve before wheel motion starts, and some top-end limiting, where it would be more efficient to run at 90% instead of 100%, and trade off a few mm/sec for a lot less current drain.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.