Quick questions about wheel speed

Support Motor controllers/drivers and motors
1

I’m trying an experiment where I compare trying to run my Romi for one meter with and without motor encoders.

So, the first test is quick and dirty. . .

I set speed to full (255), and run it for 1800ms (*math at end).

Now, I know it won’t stop immediately, but it overruns by at least a half meter. Almost a whole meter. It’s still running full at the one meter mark. So, basically, I’m wondering if the RPMs are actually greater than 150? I know there will be some variation motor to motor, but the overrun is at least 500cm.

I tested as well as I could that it was running for 1800ms, but that’s a pretty easy thing to code.

(*)Math (approximate) to arrive at 1800ms.

70mm diameter wheels = 220mm circumference
1000mm / 220 = 4.54 revolutions
So, I want to rotate wheels 4.54 revolutions. At 150 RPM, that’s running for .03 minutes (4.54/150) or 1800ms.

independent math

Put in 150 rpm and 2.756 inches yield 21.65 inches per second. A meter is 39.37 inches. 39.37/21.65 = 1.8 (approx.)

code…/https://github.com/TheCityGame/DRV8838MotorShield

#include <DRV8838MotorShield.h> //very straightforward motor class


    DRV8838MotorShield motors(7, 8, 9, 10, 11, 12); 

    void setup() {
      motors.init();
    }

    void loop() {
      int iMaxSpeed = 255;

      //test full speed for the appropriate amount of time
      motors.setSpeeds(iMaxSpeed);
      delay(1800); //comes from calculation
      motors.sleep();
    }
2

Your math is OK, I got a constant of .152505 mm / tick with the encoders on my Romi. With 1440 ticks per wheel revolution, this give a distance travelled of 219.6 mm, quite close to 220mm. I derived this constant from a series of test running for 10 s at approx 250 mm/s, measuring the exact distance travelled and encoder counts each time.

Prior implementing the encoders, I could not get consistent results as the speed varied significantly with the freshness of the batteries (different motor drivers though). When running at low speeds (~250 mm/s), my Romi can now dead-recon over more than 6 meters, with multiple turns and consistently come back to the starting point within less than 10mm position error.

I wouldn’t rely on the assumption that the motors run at 150 RPM at full speed. It is likely there is a large variability to this number.

Good luck and keep us posted, I like to see what other do with their Romi based robots!

1 Like
3

Right, I’ve already started testing the encoders and clearly they’re more accurate (but all bets are off at higher speeds, it seems) once calibrated.

In their description they say that they take 12 counts per revolution of the motor shaft. Like you said, at 120:1 gear ratio, this is 1440 counts per wheel revolution. Or, 220/1440 = .152. (approx)

The thing is, my calibration numbers were WAY OFF this number. I’m getting closer to 3 mm per click (which is what they talk about here but I think tha’ts just a coincidence).

I’m not asking for advice about this (yet). I’m going to try to figure it all out this weekend. My code could be wrong. My encoders could be reading incorrectly. It could be anything at this point.

(also, DrGFreeman. . .that was me that asked you on youTube about the Romi chassis a few weeks back. Thanks for the answer. I’m already trying to pay-it-forward with another guy.)

4

Hello.

Are you powering your motors from the battery voltage? If so, note that the motor’s speed is proportional to operating voltage. As DrGFreeman mentioned, if you are running your motors directly from the battery voltage, the speed will vary based on the charge of your battery. Also, the 120:1 Mini Plastic Gearmotor HP used with the Romi chassis has a rated free-run speed of 150RPM at 4.5V; however, the Romi uses up to 6 AA batteries, which can result in an operating voltage range of around 7.2V to 9V (depending on battery charge and chemistry). At those voltages, the free-run speed should be between 240 RPM and 300 RPM.

It sounds like you want to look into your encoder problem some more yourself before troubleshooting more here, but you check that you are counting both rising and falling edges on each encoder signal, as well as using interrupts to make sure you aren’t missing transitions.

Brandon

5

Yes, running off battery, so I suspect giving it more than 4.5v is the issue. I thought that might be it, but I didn’t have a good test for that.

As far as the encoders go…yes, I certainly have a lot more playing to do.

I just didn’t want to try to diagnose the speed thing anymore if I was operating under the wrong assumptions (which I was). Thanks.

6

So, I ended up getting the intended behavior out of this robot. I did a very simple explanation on youTube about this. This is probably an obvious video to you guys, but its the kind of thing I was looking for when I was wondering “why do I want encoders on my robot?”

Thanks for the advice.

1 Like