Motor speed stability

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.

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

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

"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.

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

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.

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.

Could you elaborate on "trigging out" please?

Thanks, Bob

: 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

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.