Subject:
|
Re: NXT Motor Encoder Accuracy and Dead Reckoning
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Sun, 13 Aug 2006 14:54:32 GMT
|
Viewed:
|
11338 times
|
| |
|
|
In lugnet.robotics.nxt, Dick Swan wrote:
> Has anyone done any experiments on the accuracy of
> the NXT motor "move to" block?
I've played with it a good bit. It seems to be extremely accurate, in that
one motor will slavishly follow the other - you can do demos like set a Move
block to drive forward 10 rotations, and while it's trying to do that pick up
the robot and hold one wheel. The other wheel will stop but overshoot, and then
come back to match the other one. Release the blocked wheel, and both start to
run again. Remarkable to watch after all the years with the RCX, and it takes
*one* NXT-G block.
> I know NXT supports PID calculations to synchronize two
> motors and run in a straight line. Can you use this to
> drive your NXT robot accurately around the sides of a
> square?
Not yet (at least at a low level), because there's no way to tell the
firmware things like wheel diameter or wheelbase for the robot, and those are
needed to tell how much of an odometry change is needed to generate, say, a 90°
change in robot heading. I was working on some MyBlocks to address this issue
(and make the solution platform-independant, so my code should work on a lot of
the robots other folks build, with different wheelbases etc.).
> "Peeves consistently finished within 3 centimeters of
> its starting position." Can/has the same performance
> been achieved with NXT using the standard NXT-G
> programming language?
I've not tried yet. Repeatability is amazingly good, considering the FW/SW
doesn't know the physical characteristics of the robot. Making things like
accurate heading changes or corresponding physical distance to odometry counts
is higher level. And high-level PID like Peeves does, correcting not just for
heading drift but the offset that comes with it, I've simply not tried. But
since all the math is there in NXT-G, it should certainly be possible. I've also
not tried running my robots slow (probably needed, as wheel slip is something to
be avoided at all cost)... but with the NXT, this just means telling the FW to
run the motors slower (no regearing needed).
Right now, I'm trying to get JennToo (a basic platform) to complete a
triangle - the user specifies the first two legs and the angle between them by
clapping at appropriate times, and the robot completes the third leg back to the
home position. It's *almost* there, since I've got MyBlocks built up that will
do things like law of cosines etc.
--
Brian Davis
|
|
Message is in Reply To:
 | | NXT Motor Encoder Accuracy and Dead Reckoning
|
| Has anyone done any experiments on the accuracy of the NXT motor "move to" block? If so, can they post their results or impressions? I know NXT supports PID calculations to synchronize two motors and run in a straight line. Can you use this to drive (...) (18 years ago, 13-Aug-06, to lugnet.robotics.nxt)
|
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
