Fixing Unstable Wheels in Autonomous Car Project

  • Thread starter Thread starter PrudensOptimus
  • Start date Start date
  • Tags Tags
    Stable Wheels
Click For Summary
SUMMARY

The discussion focuses on stabilizing the wheels of an autonomous car project using two motors and a single front wheel. Key issues include a bent front axle causing instability and veering to one side. Recommendations include using a caster wheel for better maneuverability, ensuring the axle is rigid, and implementing a "fudge factor" in the motor control code to compensate for speed discrepancies between the wheels. The conversation emphasizes the importance of empirical testing to adjust motor speeds for straight motion.

PREREQUISITES
  • Understanding of basic robotics and motor control
  • Familiarity with axle mechanics and wheel stability
  • Knowledge of coding for motor speed adjustments
  • Experience with empirical testing and adjustments in robotics
NEXT STEPS
  • Research caster wheel designs and their impact on stability
  • Learn about axle rigidity and materials for improved performance
  • Explore coding techniques for implementing a "fudge factor" in motor control
  • Investigate methods for measuring wheel speed and performance under load
USEFUL FOR

Robotics enthusiasts, hobbyists building autonomous vehicles, and engineers focused on motor control and stability in mobile robotics.

PrudensOptimus
Messages
641
Reaction score
0
Hello,

I am trying to finish a project that uses 2 motors and 2 wheels of 3in in diameter each to produce an autonomous car (although we know it is not autonomous because I'm stupid)

the problem is... the wheels tend to go up a bit and down a bit... is not stable...
how can i make the wheels more stable? and also i only use 1 wheel in the front... because 2 wheels in the front won't allow turning... somehow. and the wheel in the front is not as big as the wheels in the back.
 
Engineering news on Phys.org
Can you elaborate on the problem you're having?
 
Yes,

I have 1 wheel in the front, and bigger wheels in the posterior (back) of the object. the front wheel size to back wheel size is about 1:2.
The problem I am having is that some times the "sticks" connecting through the front wheel,... the stick that holds up the front wheel brakes. ... is it because i should put 2 wheels in the front instead? but then it seems i cannot turn properly, because in order to turn, i need to set one of the back wheels on forward motion, and the other back wheel on backward motion...
 
PrudensOptimus - for the front wheel you'll want a caster wheel like you'd see on the bottom of an office chair. This means it will give vertical support but is free to rotate in any horizontal direction. You can get them at a home center for a couple dollars. You could run one or two, it doesn't matter as they won't affect the steering.

As far as the wheels moving up and down it could be they are out of round (you'd need some sort of lathe to make them round) or it could be a bent rim or axle. Difficult to say exactly how to address that problem without seeing the object and options but its likely that some ingenuity and epoxy would be sufficient. :smile:

Cliff
 
what is epoxy? And also... any other ways other than a casterwheel? caster wheel is not allowed...
 
I'm still having trouble understanding what's actually failing. In the sentence below, you've used the word 'sticks' twice - I'm sure you mean 'axle'.

"The problem I am having is that some times the "sticks" connecting through the front wheel,... the stick that holds up the front wheel brakes"

So, what is wrong with the axle? Is the problem that, with a rigid axle, you cannot turn the front wheel?

(P.S. epoxy is just a strong glue.)
 
If you want front wheel steering you need a differential gear on the rear axle to allow the two wheels to turn at different speeds.

Personally I'd go with the free-castoring approach, though, that gives a bit better maneuverability, as with certain light aircraft such as the Grumman AA-1 and AA-5, as well as newer composite planes. And I would think that it would be easier since you don't need a servo to control your steering, just make your CPU control two motors instead.
 
Instead of needing a differential in the back, if this just a small "toy", you can just have the motor drive only one of the rear wheels. I believe even some go-karts do this. Then, you could have single wheel up front for steering and/or braking, and one wheel in the back for power, and you won't need caster's, and a 2 motor on both 2 rear wheel configuration.
 
Do you mean that all 4 wheels drive and the front wheels slide along the ground because they turn at a different speed than the rear wheels?
 
  • #10
Ok here's the problem now.

There's one axle in the front connecting 1 wheel.

but when you lay down to see it from the anterior, it looks like it is bent downward.

How big of a problem is that and how do i solve it...

And also... would not caster wheel cause a problem with "straight" motion, when I set both back wheel motors to straight motion?

And also... why does the object tend to shift to one side (lets say toward right) when I set both rear wheel motions to forward at same speed?

And how do I find speed of the wheel, given I know the distance? is it simply distance/time? ... is there a possible way to correct this "shift toward right problem" using coding or mechanically?

Pardon me for such abrupt questions and somewhat inquisitive nature.
 
  • #11
The front axle is bent downward? What do you mean by "downward?" Is it not perfectly horizontal? On an automobile, this would cause uneven tire wear and more than likely bad vibration, but on a little toy car, I assume it wouldn't cause much more trouble than a slight pull to one side or the other. If that wheel up front is just there for stability, I woudn't worry too much about it.

As for a caster, I agree and thinkg this would be your best bet up front. It doesn't require an axle and you'll get just as good manuverability. It will actually be best during straight motion. The only time you'll have any trouble is when going from reverse to forward (or vice versa) when the caster has to swivel back around.

As for the speed of the wheel, it depends on what speed your talking about. Are you talking about angular velocity? Straight line velocity of the center, linear velocity of a point on the wheel??
 
  • #12
Hi thanks for the prompt response,

I am interested in any speed that can tell me if the 2 motors are rotating at different speeds so I can use code to adjust so as to not let the toy car shift toward one side. (right now the toy car's encoders report the same readings on both wheels, but... still the car tends to go right. what is the problem. pls help)
 
  • #13
> when you lay down to see it from the anterior, it looks like it is bent downward.
Please, you must be more specific if you want specific answers.
Is the axle supported at both ends (on each side of the wheel?), or just on one side?
What kind of bending downward? Is the axle is shaped like a smile :smile: ? or like a frown? :mad:
If it's a frown, then the ends are bent down, suggesting the axle is too weak for the weight of the chassis.
If it's a smile, I guess the axle is bent.
Either way, you need either less weight, or a stronger axle.

You could put less weight on the front axle by moving the whole wheel closer to the centre of mass.


>And also... would not caster wheel cause a problem with "straight" motion, when I set both back wheel motors to straight motion?

No, why would it?

>And how do I find speed of the wheel, given I know the distance? is it simply distance/time? ...

You mean rotational speed? RPMs?


>And also... why does the object tend to shift to one side (lets say toward right) when I set both rear wheel motions to forward at same speed?

Because your motors are not operating at exactly the same speeds. Not much you can directly do about that, but you might find some creative ways to compensate for it.

>is there a possible way to correct this "shift toward right problem" using coding or mechanically?

Sure. Alter the motor's speeds slightly. Make one tire a slightly different size. Apply friction to one wheel. But you're only compensating, you're not really correcting the problem.

I doubt you will get rid of all the veering with any of these methods. If you really want straight motion, I suspect you may need to consider a different drive mechanism i.e. not one motor per wheel.
 
  • #14
Well...automotives use a little magenetic piece in the differential to detect speed (or something in the distributor I believe). Anyways, the magnetic piece spins around and generates a magnetic flux through a coil of wire (basically). This magnetic flux generates a voltage which the computer picks up. It times those voltage spikes and calculates velocity based on that. I'm not sure what you have access to determine velocity
 
  • #15
>I am interested in any speed that can tell me if the 2 motors are rotating at different speeds so I can use code to adjust so as to not let the toy car shift toward one side. (right now the toy car's encoders report the same readings on both wheels,

The motor will have a margin for error.


>but... still the car tends to go right. what is the problem. pls help)

You've mentioned coding and motors. I presume you have some sort of language that let's you program the motors.

Do the test empirically, regardless of what the encoders tell you.

Add a variable to your equation for speed on one wheel (say, the right). Let it vary both positive and negative.
Set it to zero, run the car.
If it veers right, adjust the variable postively - so that it speeds up the wheel slightly.
Repeat the test.
 
  • #16
the axle is bent like a frown... and the axle is umm actually 2 axles connected together by a "connector" thingie. And in the middle is my tire. Would this bending cause motion problems? And the axle as a whole is supported on both ends.

Here's what I have in coding to solve the rotational problems... I'm sure it is not right, but please advice

if ( read_encoder ( left_wheel) < read_encoder( right_wheel )
{ // increase left wheel power
motor(left_wheel, current_speed + ++i );
}

is that right?? how can I find precise speed within 2 seconds? rather than RPMs...
 
  • #17
minger said:
Well...automotives use a little magenetic piece in the differential to detect speed (or something in the distributor I believe). Anyways, the magnetic piece spins around and generates a magnetic flux through a coil of wire (basically). This magnetic flux generates a voltage which the computer picks up. It times those voltage spikes and calculates velocity based on that. I'm not sure what you have access to determine velocity

Ground velocity can be easily calculated using the RPMs and the circumference of the wheel. Note that you must take the reading while the car is under load, or you will get an inaccurate reading on RPM.
 
  • #18
but RPM is distance/60seconds... say now I have 4RPM on left wheel and 5 RPM on right wheel,

I have to speed up left wheel... how do I know when will the left wheel and right wheel have same RPM? it takes another 60 seconds to calculate the new RPM for left wheel ...

Btw, do you have AIM? I really need help.
 
  • #19
PrudensOptimus said:
the axle is bent like a frown... and the axle is umm actually 2 axles connected together by a "connector" thingie. And in the middle is my tire. Would this bending cause motion problems? And the axle as a whole is supported on both ends.
Sounds like you need a more rigid axle.
BTW, does the axle actually rotate? Or is fixed and only the wheel in the middle rotates?

PrudensOptimus said:
Here's what I have in coding to solve the rotational problems... I'm sure it is not right, but please advice

if ( read_encoder ( left_wheel) < read_encoder( right_wheel )
{ // increase left wheel power
motor(left_wheel, current_speed + ++i );
}

is that right??
My understanding was that, even when the wheels reporting rotating at the same speed, you were having veering.

What you want is a "fudge factor", thus:

var fudge_factor = 0.0; //independent value to compensate for margin of error between motors

...

function motor(wheel,speed){
blah blah blah;
// return final_speed; << old
return (final_speed + fudge_factor);
}


So, this fudge factor is outside all other calculations. "Left wheel, when I tell you to rotate at 63 RPMs, I really want you to actually rotate at 64 RPMs.

You determine the fudge factor experimentally. If it's veering a lot, make the variable large. If it's veering a little, make it small.
 
  • #20
the axle rotates... if it doesn't then the car have hard time going... and also... is it easier to make 90 degree turns with 1 wheel in the front or 2 wheels?
 
  • #21
PrudensOptimus said:
but RPM is distance/60seconds... say now I have 4RPM on left wheel and 5 RPM on right wheel,

I have to speed up left wheel... how do I know when will the left wheel and right wheel have same RPM? it takes another 60 seconds to calculate the new RPM for left wheel ...

OK, but my solution has nothing to do with what the mechanism is reporting the speed to be, so the calculation of the RPM is not necessary.

Your left wheel reports 4 RPMs.
Your right wheel reports 4 RPMs.
Yet your car still veers.
Add a fixed to one of the wheels to make it spin at 4.1 RPMs.
Run your car again. If it still veers, set the fudge factor to +0.2.

You see, it has nothing to do with the values the car is reporting. It is just a fixed value, set manually to offset a fault in the physical aspects of a device.



PrudensOptimus said:
Btw, do you have AIM? I really need help.
Sorry.
 
  • #22
so you are suggesting Encoders dun do nothing other than reporting the distance traveled?

and the shift left & right has to be corrected through empirical tests?
 
  • #23
DaveC426913 said:
Ground velocity can be easily calculated using the RPMs and the circumference of the wheel. Note that you must take the reading while the car is under load, or you will get an inaccurate reading on RPM.

Yes, but how do you find RPM, that's the thing.

but RPM is distance/60seconds... say now I have 4RPM on left wheel and 5 RPM on right wheel

Instead of using time as a constant and calculating distance, try it the other way. You can find your distance, that is simply the circumference of your tire. Calculating how much time it takes for the wheel to go around will give you a value for RPM updating itself everytime the wheel rotates.

I agree with the "fudge factor" idea. Keep your current code where it looks at the two individual wheel rpms, but add a factor in there as a constant. The problem is that the computer "thinks" that it's going straight because it thinks that 4 = 4. I think perhaps 'after' the check, you need to insert the fudge factor to correct for irregularites.

Either that or find someway to calcuate 'actual' RPM and not just what the motor is telling you.
 
  • #24
PrudensOptimus said:
so you are suggesting Encoders dun do nothing other than reporting the distance traveled?

and the shift left & right has to be corrected through empirical tests?
Yes, its not necessarily true that such things will function identically straight out of the box. Applying correction factors is not an unusual necessity.
 
  • #25
We call that "calibration" in our circles.

There's a fine line between calibrating and fudging.

BTW...I believe most cars these days use the speed signals created by the anti-lock brake systems (at least that was happening back when I used to work for Ford).
 

Similar threads

Replies
9
Views
2K
Replies
1
Views
575
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 7 ·
Replies
7
Views
9K
  • · Replies 22 ·
Replies
22
Views
4K
  • · Replies 20 ·
Replies
20
Views
5K
  • · Replies 9 ·
Replies
9
Views
6K
  • · Replies 6 ·
Replies
6
Views
8K
  • · Replies 10 ·
Replies
10
Views
6K
  • · Replies 7 ·
Replies
7
Views
3K