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 21:00:02 CDT 2003 ```Okay, sorry, where was my brain? Missing when I wrote the last post, most likely. The difference in velocity of the 2 wheels is dictated by the 2 different circumferences that you want them to traverse. For example if you want to arc left around a point 5 inches to the left of the robot for 1 second then the left wheel needs a velocity of 2*PI*5 in/sec. If your robot is 4" wide, the right wheel then needs a velocity of 2*pi*(5+4) in/sec. The relationship is defined by the distance between he wheels on your robot. As was previously mentioned, it may be much easier to do this math in encoder tics/internal robot state update. -Kenneth (Unit 3's in trouble and it's scared out of its wits) -Geddy Lee ----- Original Message ----- >From: "Dale Wheat" To: "Kenneth Maxon" Sent: Saturday, June 07, 2003 6:40 PM Subject: Re: [DPRG] Motor control > Kenneth, > > I believe you are right. What I wanted to know was the relationship between > the values used for linear velocity (Velocity) and angular velocity > (Rotation) for an arc of a given radius. > > For example: The robot should start going forward and arc to the left. I > want the radius of the arc to be 5 ft (let's call that 5,000 encoder units > for those who don't like to mix units). If the linear velocity is set to > some reasonable value, what would the angular velocity (Rotation) be? > > There's got to be a geometric way to figure this out, and not resort to > empirical methods. Or maybe not. I'd like to know if this approach > supports this. > > Thanks, > > Dale Wheat > http://dalewheat.com > (972) 486-1317 > (800) 330-1915, access code 00 > > ----- Original Message ----- > From: "Kenneth Maxon" > To: "Kipton Moravec" ; "Dale Wheat" ; > > Sent: Saturday, June 07, 2003 8:31 PM > Subject: Re: [DPRG] Motor control > > > > 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