Subject:
|
RE: another comparison
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 21 Jan 2007 15:43:49 GMT
|
Reply-To:
|
<{dickswan@sbcglobal.net}avoidspam{}>
|
Viewed:
|
3226 times
|
| |
|
|
Chris Phillips wrote on Sunday, January 21, 2007 7:38 AM
"My gut tells me that the RCX (using BrickOS) would give the NXT (using
anything available so far) a good run for its money, though..."
Once you reach a certain base performance level, then it doesn't really
matter to most users what the actual real time performance is. NXT-G may
be relatively slow when compared to the emerging alternative programming
environments; it's certainly the case when it is compared with RobotC.
But NXT-G exceeds the base performance level so perhaps it doesn't
really matter.
Far more relevant is the choices made in the underlying
implementation/algorithms. I'll use your example of PID algorithms to
illustrate this principle. The relevant factors here include:
* How often is the PID loop updated?
* Are the PID factors properly tuned?
* Has the right "equation" / "definition" been chosen for the PID error
factor?
An observation of the NXT-G movement of two synched motors driving in a
straight line before stopping after a specified distance shows that it
achieves very reproducible results and does a great job of going
straight and stopping at the target. Most users are likely to be happy
with that. But it can be improved on! Looking at the "straight" line PID
results in detail you'll notice:
* A slight "oscillation" about the ideal line as the robot moves.
* There's a very slight (and reproducible) "curvature" to the line --
typically 0.1 to 0.25 inches for every 3 feet of travel.
* There's always overshoot at the end point. Followed by a correction to
move back to the target spot.
Analyzing the root cause of the above observations in more detail leads
to the following:
* PID loop is updated every 100 msec. A faster update cycle might reduce
the maximum error of the oscillations.
* There is only a PID used to adjust the synched motor speeds. A full
PID is not used to stop at the end-point; just a simple ramp down of the
speed as the end point is reached. Use of PID here (the "D" factor)
would allow stopping at the end point and avoid the overshoot.
* The PID error factor is to ensure that the speeds of the two motors
are synchronized. It is not to ensure that the robot travels in a
straight line! This is the cause of the curvature.
Addressing the above points, rather than execution speed improvement,
may yield the best improvements. For example, a better choice for the
error factor would be the deviation from the straight line movement --
which can be easily calculated from the motor encoders and a little
trigonometry.
The above performance is more than good enough to drive in a single
"straight" line. But one of my current interests is in super-accurate
dead reckoning -- i.e. lots of movements, turns, etc -- with accurate
recording of location. You need great accuracy in the individual
movements to minimize the accumulated error. I suspect the LegoBot Robot
from David Anderson (five years ago, Handyboard based, see
http://www.geology.smu.edu/~dpa-www/robo/lego/index.html) has
established a good benchmark; I've seen it randomly wander around a 10'
x 10' walled rectangle for five minutes and then consistently return to
within 2" of its original starting point. This is really impressive and
not something that I expect to see in a NXT-G program!
And this brings me back full-circle on the performance issue. Accurate
dead-reckoning needs trigonometry and transcendental functions (sqrt,
sin, cos, atan) with floating point numbers. Even though you can
implement these in NXT-G subroutines/blocks, my gut tells me the
performance won't be good enough. For this level of accuracy, maybe
NXT-G is not good enough.
And a practical example of dead reckoning movement is the annual FLL
tournament. Imagine a development environment that had a pre-built
library of dead reckoning routines -- e.g. give the robot a list of
coordinates/waypoints and it will move to each of them. This could
dramatically simplify the required programming. Some robots in the FIRST
tournament (the tournament with bigger robots for older kids) have been
using this technique for the last couple of years in the autonomous
operation section. I expect to see some dead reckoning solutions for FLL
next year!
And back to your original "gut" feel. BrickOS may give NXT-G "a good run
for its money" but I doubt if the same will be true of the faster
alternative text-based programming languages. See my recent post on
this.
Following up on your sampling rate question. "Standard" (i.e original)
firmware for RCX and NXT samples the sensor ports at 3 msec. But the NXT
motor encoders are interrupt driver and can support over 1,000 counts
per second. On the RCX, sampling speed in the Robolab firmware is now
customizable down to 0.5 msec so that you can get legacy rotation
sensors to reliably work at up to 1,400 counts per second. Unfortunately
in the NXT the analog sensor sampling rate is fixed at 3 msec and cannot
be changed since it is done in the slave AVR microprocessor.
|
|
Message is in Reply To:
 | | Re: another comparison
|
| (...) Perhaps a good benchmark would be to write a PID controller and measure the number of control loop iterations per second that can be achieved under each environment. This incorporates sensor input with motor output, and uses a moderate amount (...) (18 years ago, 21-Jan-07, to lugnet.robotics)
|
11 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
