Loading ...
Sorry, an error occurred while loading the content.

Re: [SeattleRobotics] Re: this humanoid biped is probably ...

Expand Messages
  • tbrenke@verizon.net
    to me, connected to a PC is not a robot. this is a remotly controled object. if you can stuff all that into a selfcontained item, then it is a robot.
    Message 1 of 76 , Sep 1, 2005
    • 0 Attachment
      to me, connected to a PC is not a robot.
      this is a remotly controled object.

      if you can stuff all that into a selfcontained item, then it is a robot.


      Brian Dean wrote:

      >On Thu, Sep 01, 2005 at 04:42:44AM -0000, dan michaels wrote:
      >
      >
      >
      >>--- In SeattleRobotics@yahoogroups.com, "tbrenke@v..." <tbrenke@v...>
      >>wrote:
      >>
      >>
      >>>did you also see that this "robot" is connected to a PC?
      >>>
      >>>
      >>>
      >>
      >>
    • Brian Dean
      ... Do you have an encoder or a potentiometer? If encoder, then you need to keep track of position - the starting position will be your zero , i.e.,
      Message 76 of 76 , Sep 13, 2005
      • 0 Attachment
        On Mon, Sep 12, 2005 at 01:44:30AM -0000, Bryan wrote:

        > What I have been doing is balancing the pendulum and then turning on
        > the micro. That sets the current "balanced" angle to 0. Then I just
        > use the angle from there as the proportional. I guess it would make
        > sense to know my desired angle, but I am not exactly sure how to do
        > that with this encoder. I also have an angular velocity gain which is
        > just a newAngle-oldAngle. Does that clarify?

        Do you have an encoder or a potentiometer? If encoder, then you need
        to keep track of position - the starting position will be your "zero",
        i.e., vertical. Similar if you are using a pot - the vertical will be
        the A/D value when you power on the micro assuming the pole is
        balanced at that point.

        Sounds to me that a classic PID calculation would produce good results
        for you. There are plenty of resources on the web for this - use
        Googlew. I'd probably start with just a PD loop, I doubt an "I" term
        will be all that beneficial in your setup.

        The equations are very simple to implement and apply. The trick is
        setting the gains.

        Start with a D gain of zero. Set the P gain high enough so that you
        can deflect the pole and your system will move the base quickly enough
        under the pole to keep it from falling. Some overshoot is OK here,
        not too much, i.e., not so much that the pole falls too far the
        opposite way. Some oscillation is OK at this point.

        When you have the P term controlling the pole in that way rather
        coursely, start increasing the D gain. The D term will dampen the
        effect of the P term and make the overall motion smoother.

        Too much D or not enough P will make the response too slow to balance
        the pole and it will fall over.

        Too much P and not enough D will make the system unstable, over
        correct and oscillate, perhaps wildly.

        With these two knobs, you should be able to fine tune the response.
        Of course, the driving mechanism must be fast enough to move the base
        of the pole to keep it from falling over. If your motor is not quick
        enough to begin with, then that will limit how steep of an angle of
        deflection you can recover from. Also, how wide of a travel for your
        base will affect this also, as I think Tony Brenke alluded to earlier.

        -Brian
        --
        Brian Dean
        ATmega128 based MAVRIC controllers
        http://www.bdmicro.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.