To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 25628
25627  |  25629
Subject: 
Re: turtle coding kit (Re: How would we (the rest of us) communicate ideas to the MDP?)
Newsgroups: 
lugnet.robotics
Date: 
Wed, 22 Feb 2006 15:47:38 GMT
Viewed: 
6636 times
  
In lugnet.robotics, Tim Rueger wrote:

> > Given the choice, I'd like to see included in NXT
> > a software module for coding dead-reckoning
> > navigation for turtle-type robots, kind of like
> > here:
> > 
> >   http://www.seattlerobotics.org/encoder/200108/using_a_pid.html
> > 
> > But since the NXT motors have built-in encoders,
> > the code would be much simpler.  In fact, the inputs
> > to the routines would be just the diameter of the
> > wheels and their separation.

   The question is just how much of this is handled at what level within the NXT
firmware & software. I'd be surprised if LEGO doesn't do *something* with the
built-in encoders - after all, *they* put them there. the question is how much.
   The other point is that the Peeves code is really nice - and tuned. tuning
PID isn't all that easy, from what I've seen. In other words, I don't think an
"out of the box" solution will have nearly the abilities of Peeves in this
regard. But it's a great starting place. Hopefully, some of this will be
implimented out of the box, and the rest will be implemented by AFoLs (or non-A
FoL's - there's a lot of very sharp younger folks out there) shortly thereafter.

> > Credit Evan Ryker, a member of my recent FLL team,
> > for the sending me this excellent link.  Apologies
> > if it's been seen before here.)

   It has, but don't apologize - it's a great link that should be pulled up now
and again, *especially* now that encoders will come in the "base" Mindstorms
set. PID (or simpiler correction schemes) may become a lot more common. Time to
read up...

> if NXT is to be an "iPod for robotics", I think
> this has to be included, and be dead-on reliable.
> Then FLL teams... can get on with the business of
> coding actual robot behaviors instead of endlessly
> tweaking one-shot navigation routines.

   I don't know - a lot of good FLL robots don't bother with complicated
dead-reckoning, but use either "point and shoot" techniques, or correct based on
landmarks. Having three encoders opens up some wonderful new options - but some
of the old "KISS" methods shouldn't be ignored either.

--
Brian Davis



Message has 1 Reply:
  Re: turtle coding kit (Re: How would we (the rest of us) communicate ideas to the MDP?)
 
(...) I'd go further than that - I may be wrong here, but AFAIK professional roboticists largely consider dead reckoning to be a losing game, an amateur red-herring that you can waste all the time and money you want on and it will still never work (...) (21 years ago, 22-Feb-06, to lugnet.robotics)

Message is in Reply To:
  Re: turtle coding kit (Re: How would we (the rest of us) communicate ideas to the MDP?)
 
(...) Having given this a bit more thought, the code would be almost the same. Even though the encoders are built-in, there's no guarantee that the motors themselves are matched. You would still need control loops to ensure that the motors rotate at (...) (21 years ago, 22-Feb-06, to lugnet.robotics)

18 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR