Motor speed stability

I'd like to intruduce a topic of discussion, just a debate of opinions about motor speed stability.
How much variabilty around a set speed is appropriate?
The motors in a robot are not infintely powerful. Application of torque against a load results in acceleration. Then we modulate or reduce the torque to maintain a constant speed.
Various control algorithms take error of actual speed against projected speed and either increase or decrease the power to the motors to maintain a constant speed. (I am writing about speed being the feedback, no other measure at this time.)
Quick changes in the load which exceed the systems response time affect the output speed. Changes in load that exceed a motor's torque affect speed or even stall. Slow and small changes in load should not affect speed very much at all.
In a moving robot what is an acceptable speed variation in normal operation? Obviously, the answer is that "it depends," but for the sake of discussion, what are your feelings about this?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

My feeling is that it's not that important, as long as it's more or less constant. I think that mobile robot applications mostly have a position goal and not a speed goal. As such, speed is not really important, as long as it is within safety and other limits and as long as position information can be derived, measured or otherwise obtained.
Just my 0.02
Andras Tantos
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Andras Tantos wrote:

I really do appreciate your input. I may come off differently, but I really like discussing ideas, especially if they are different. I learn so much defending my position. I am presented with viewpoints that I may otherwise not have seen.
In this case, you are exactly right and put my "gut" feeling into words, i.e. mobile robotics is more a positional task than one about velocity. I was struggling with this very issue and failed to see it. Actually, speed is not totally out of equasion if you have a diametrically opposed wheel robot, but point well stated.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"mlw"

Not trying to hijack your thread, but if we are talking about mobile robotics (and that's the one I'm more interested into lately), then a more critical point I believe would be instead of precisely controlling the speed, precisely sensing your position.
Well, there are the standard ways, GPS, odometry and etc. But they all have big flaws and disadvantages. What would be then a viable and reliable alternative?
I put some thought on that lately, here are some ideas: - A camera (and some light source?) pointing down and scanning the terrain. Compare frames and then try to determine direction and movement . - Landmark detection and tracking, perhaps with the help of satellite imagery or topographic maps
I do know that I'm not inventing anything new, and I'd easily find lot's of research papers on both subjects, but I think it's worth taking a look. At least I will when I get to the point of implementing the navigation on my robot.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mlw wrote:

You touched on the only case where tight speed control in a hobby type robot is important, the differential drive 'bots. Speed errors become course errors in this configuration. I have seen a couple of papers on the net where the error signal from one side is used to adjust the commanded velocity of the other side. Other than a hexapod, I keep playing with differential drive machines.
Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Contrary to what I have seen others report, I have experienced excellent position tracking with mobilt robots simply by "trigging out" wheel rotation. Constant speed is very nice to have for these purposes.
In addition, I have to believe that there may be efficiency issues at hand as well, purposefully slowing down on level floor because that degree of slowing is within a tolerance band, then regaining that speed again is a waste of energy.

long
really
otherwise
I
speed
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

Could you elaborate on "trigging out" please?
Thanks, Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Doing all the trig calculations to determine where you are. I suppose one could do it better with Calculus though.

hand
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

If you do the course corrections from the position calculated from your odometry and then correct the course accordingly, does this differ in any major way with respect to efficiency from just modifying the commanded velocity of the wheel that did not slow down? I guess that the corrections would be slower and might pick a slightly different course, resulting in less energy used.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
: My feeling is that it's not that important, as long as it's more or less : constant. I think that mobile robot applications mostly have a position goal : and not a speed goal. As such, speed is not really important, as long as it : is within safety and other limits and as long as position information can be : derived, measured or otherwise obtained.
The method I'm using turns the problem arround: Implement a low-level positional PID, and controll speed by moving the set-point position the speed you want your robot to go.
I recall a post about it in this newsgroup a few years ago that called it the "moving the rabbit" approach (after, I assume, the rabbit at a dog track). I've taken my method directly from http://www.barello.net/Papers/Motion_Control/index.htm .
--
==========================================================
Chris Candreva -- snipped-for-privacy@westnet.com -- (914) 967-7816
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Christopher X. Candreva wrote:

I'm toying with a number of different ideas. The structure of my system involves the notion of a "planner" object that can set the target for each iteration of the PID loop.
There is a manual planner uses a user controlled velocity sort of mechanism. I have another version that allows pre-programmed motion that works similarly to the "moving rabit" (interesting naming) technique.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

operation?
discussion,
It depends :-)
If we are talking about a mobile robot, I'd say speed variation is not as great a concern as it is in a laser cutting, welding or sealant robotic arm. Last semester I saw a video of a robot that plays ping-pong. Then speed control is even more critical and dynamic. Additionally to using a PID controller, they've implemented a trajectory generator that kept speed, acceleration and jerk under a precisely defined quintic polynomial curve. Actually, one of the consequences of implementing such generator is to increase overal stability of the system.
When learning about controllers, DC motors and robotic arms, the professor always simplified the link effect as being a cylinder. If you think about that, it is really difficult to model the forces a joint suffers from the link as many things will play a role in it. Gravity, position of the links and external forces are some of them.
Padu
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.