DPRG List

 [DPRG] Motor control Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] Motor control Next message: [DPRG] Motor control Subject: [DPRG] Motor control From: Kenneth Maxon kmaxon at uswest.net Date: Sat Jun 7 20:27:01 CDT 2003 ```In David's system to implement an arc wouldn't one command a rotation at the same time as a translation? -Kenneth (Unit 3's in trouble and it's scared out of its wits) -Geddy Lee ----- Original Message ----- >From: "Kipton Moravec" To: "Dale Wheat" ; Sent: Saturday, June 07, 2003 5:45 PM Subject: Re: [DPRG] Motor control > At 02:15 PM 6/7/03, Dale Wheat wrote: > >David, > > > >Thanks for the good information about motor control. Thanks also for > >explaining it to me in agonizing detail last Tuesday. Although I'm chomping > >at the bit to understand PID motor speed control algorithms (which will be > >fun, because I barely know what an integral (The I in PID) is and until last > >Tuesday had no clue what a derivative (The D in PID) was), I have to make > >sure I completely understand what has been covered so far. > > > >As usual, I'd like to go over a few points in some more detail, mostly > >concerning units of measure. Please correct me if my assumptions are > >incorrect. > > > >The "arbitrary scale" of -100 to +100 in the first method expresses a value > >of power applied to the motors. This is "open-loop power control" and does > >not take into account variations in motors/gears/wheels, friction, voltage, > >slopes, etc. Applying an equal amount of power to both wheels does not > >guarantee driving in a straight line. > > > That is correct. That is "open-loop" control. By getting feedback from a > sensor, like wheel encoders, you know how much the wheel turns, or the > distance traveled. That is "closed-loop" control. The PID algorithm > generates an estimate necessary to spin the wheels dispite the differences > in "motors/gears/wheels, friction, voltage, slopes, etc." > > > > >The next step involves dealing with the abstract quantites velocity and > >rotation. Velocity is defined as distance over time. For our purposes, the > >distance can be measured in shaft encoder counts (which hopefully can be > >accurately translated into some more traditional linear measurement like > >feet, inches, furlongs, parsecs, etc.), while the time is broken down into > >the units between each measurement made. On SR04, for example, the time is > >50ms, since measurements are taken 20 times a second. So (linear) velocity > >is expressed as encoder counts over timer ticks. > > That is correct. > > >Rotation (or more accurately rotational velocity) is defined as angular > >displacement over time. To use the equations presented, where rotation is > >added or subtracted from the left and right velocities, respectively, the > >units of measure would of course have to be the same, namely encoder counts > >over timer ticks. If the wheelbase (the effective distance between the > >wheels) is expressed in encoder counts, then the angular displacement can > >also be expressed in radians, using one of the odometry equations, > >specifically "theta = (right - left) / wheelbase". The rotational velocity > >can then be expressed as the angular displacement (either in radians or > >encoder counts) per timer tick. > > > >If the observer (me) is looking down on the robot from a height (and until I > >build a flying/hovering robot, I will be), rotation to the left > >(counter-clockwise) would be expressed as a positive angle and rotation to > >the right (clockwise) would be a negative angle. Since turning to the left > >necessitates slowing down the left motor, or speeding up the right motor (or > >both), shouldn't the equations be: > > > >Left_motor = Velocity - Rotation > >Right_motor = Velocity + Rotation > > > >instead of the other way around? > > It depends on how you define your coordinate system. In general I do not > like to mix units, so velocity and rotation can not be added or subtracted > from each other. Always work in common units. If you are working with > speed, then stay in encoder ticks/ sec, or radians/timer tick or whatever > you want. But do not mix them up. As a general rule, a good working > system is to stay in encoder ticks/timer tick. That makes most of the > lowest level calculations dealing with simpler integers, and not as complex > other units like feet/sec. If you need feet/sec you can convert only when > you need it. > > > >This next step seems like it will make things much simpler when traveling in > >a straight line (I wish!) or turning in place, but what about describing an > >arc? It seems to me that it would be easier or at least more accurate to > >make a turn about a point other than the center of the robot, since the > >measured distances would be larger and suffer less from round-off error in > >odometry, or would these benefits be outweighed by the increased cumulative > >navigational error? It occurs to me that there should be a simple way to > >express this given the level of abstraction already in place. The exact > >translation escapes me at the moment. Also, since all my robots seem bound > >and determined to travel in arcs, anyway, I think it would be wise to "go > >with your strengths" and find a way to let them do what they do best, and > >still do what I want. > > To describe an Arc one wheel turns at so many encoder ticks/timer tick, and > the other wheel runs at a different encoder ticks/timer tick. (Don't > forget you have to take into consideration the different diameters of the > wheels.) > > > > >Any thoughts would be appreciated. All you other nav-geeks feel free to > >pitch in. The last couple of days' discussion on "dead reckoning" have also > >been enlightening. > > I would probably have "canned" arcs that I could choose from if that is the > way you want to go. Calculate the speed (encoder ticks / timer tick) for > how many ticks for each wheel to make the arc you desire. > > > >Thanks, > > > >Dale Wheat > >http://dalewheat.com > >(972) 486-1317 > >(800) 330-1915, access code 00 > > There is another approach to the problem. That is to route plan for every > tick. Prior to reading the encoder value, you calculate what it should be > to be on the path you desire at the speed you want. You do this for each > wheel, and the wheel tracks the given path. This is different then the way > David does it. > > David's approach commands the wheels to go at a certain speed. The PID > Controller gets the wheels to that speed and holds that until something > changes. It is hard to predict the ramp-up and how fast it will reach the > desired speed. This can cause errors when turning. > > The approach I described you would set the ramp up for each sample. It is > a tighter control, (and hopefully if used correctly) would reduce the > angular errors (for turning). > > It is a little more complicated as you have to have a route planner as well > as the PID control to stay on the route. > > Kip > > > >----- Original Message ----- > >From: "David P. Anderson" > >To: > >Sent: Saturday, June 07, 2003 11:18 AM > >Subject: [DPRG] Motor control > > > > > > > > > > Howdy > > > > > > As per our discussion of motor control from last week's > > > RBNO, I thought I'd try to summarize the scribblings on > > > the whiteboard and perhaps clarify a couple of points. > > > > >(omitted) > > > > > Left_motor = Velocity + Rotation > > > Right_motor = Velocity - Rotation > > > > >(omitted) > > > > > > Next week, the PID Speed Controller... > > > > > > hope this helps! > > > cheers, > > > dpa > > > > > > _______________________________________________ > > > DPRGlist mailing list > > > DPRGlist at dprg.org > > > http://nimon.ncc.com/mailman/listinfo/dprglist > > > > > > > > > >_______________________________________________ > >DPRGlist mailing list > >DPRGlist at dprg.org > >http://nimon.ncc.com/mailman/listinfo/dprglist > > _______________________________________________ > DPRGlist mailing list > DPRGlist at dprg.org > http://nimon.ncc.com/mailman/listinfo/dprglist > ``` Previous message: [DPRG] Motor control Next message: [DPRG] Motor control Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list