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

Output Data Format

Expand Messages
  • jtennys
    I am working with a KHR2 with an SBC attached to it (Linux 2.4, soon to be 2.6). The next step in my project is to be able to convert Controller commands to
    Message 1 of 6 , Sep 2, 2009
      I am working with a KHR2 with an SBC attached to it (Linux 2.4, soon to be 2.6). The next step in my project is to be able to convert Controller commands to scripts for my servo controller board. I have been looking at a conversation that you had with someone on this board a couple years ago (Tekkotsu 3.0) about "Sending PID values along with Images," but I think that my problem differs from that particular one.

      I will eventually be running Tekkotsu on the robot, but controlling it with the GUI on a remote system. I needed to be able to read the final calculated positions from Tekkotsu into a program so that I could do my conversion to servo commands for my particular board. I assume that what I want to do is poll MotionHook (via a driver) for data and send it to my program, but will this give me all of the data in posture format, or a different format? Also, I notice that for example, the Create driver doesn't have anything but sensor declarations and no motor declarations (that aren't commented out). Nonetheless, do I want to model my KHR2 driver after the Create files?

      Any help is appreciated,
      Jason Tennyson
    • Ethan Tira-Thompson
      Yeah, I think your problem differs from the referenced thread. In particular, since you will be running Tekkotsu onboard the robot, you can hopefully use the
      Message 2 of 6 , Sep 2, 2009
        Yeah, I think your problem differs from the referenced thread.

        In particular, since you will be running Tekkotsu onboard the robot,
        you can hopefully use the ControllerGUI stuff as-is without needing to
        look under the hood. (which is good, because that section is fairly
        ad-hoc)

        Instead, you have the right idea to use a MotionHook interface.
        You'll also need a thin DeviceDriver class to wrap the MotionHook (and
        eventually perhaps interface with associated sensors via DataSource).

        These are the key bits of documentation:
        http://tekkotsu.no-ip.org/porting.html#hardware
        http://tekkotsu.no-ip.org/dox/hal/classMotionHook.html

        The MotionHook::motionCheck() is your sugar daddy. That will be
        called by the framework whenever new joint positions have been
        calculated. So if your driver is created (from HAL command line: new
        YourDriver [optional-name]) then it will immediately start receiving
        joint values. You may prefer to override motionUpdated(), which is
        called by the default motionCheck() implementation with only those
        joints which have changed since last update.

        I might recommend looking at the SSC32 driver too, I'm not sure if
        that is closer to the KHR2 interface. (if there's some documentation
        for the KHR2 interface, I could skim it and give you more specific
        advice.)

        As a heads up, the CommPort system is helpful for flexible execution.
        For example, if you wish to run off-board for quicker development
        turnaround, you could use a NetworkCommPort and stream your KHR2
        commands over the network. But then for onboard execution you would
        use (assuming) a SerialCommPort instead. (If I'm right about the
        serial port usage, this also avoids you having to reimplement annoying
        serial port configuration stuff) This is all done by the HAL, so your
        driver just receives the generic CommPort interface, and the HAL
        worries about creating and configuring it.

        Also, I just realized the DataSource documentation on that first link
        is outdated... the LoadDataThread is gone, so if you write a
        DataSource for sensors its up to your driver to push updates out when
        available (i.e. might need your own thread), instead of having your
        class polled for updates in the previous setup.

        -Ethan
      • jtennys
        The SSC32 does look more like what I want. I basically want a driver that collects data from Tekkotsu and exports it to another set of files or a program that
        Message 3 of 6 , Sep 3, 2009
          The SSC32 does look more like what I want. I basically want a driver that collects data from Tekkotsu and exports it to another set of files or a program that translates the data into something meaningful for my servo controller. It looks like the controller data is dumped and compared with the current positions and changed with setServo, which is all stored in "outputs", that I could read with my files (or just include in the driver). Thanks for the info, I'll try to dig deeper and make sure my assumptions are correct.

          Jason Tennyson

          --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
          >
          > Yeah, I think your problem differs from the referenced thread.
          >
          > In particular, since you will be running Tekkotsu onboard the robot,
          > you can hopefully use the ControllerGUI stuff as-is without needing to
          > look under the hood. (which is good, because that section is fairly
          > ad-hoc)
          >
          > Instead, you have the right idea to use a MotionHook interface.
          > You'll also need a thin DeviceDriver class to wrap the MotionHook (and
          > eventually perhaps interface with associated sensors via DataSource).
          >
          > These are the key bits of documentation:
          > http://tekkotsu.no-ip.org/porting.html#hardware
          > http://tekkotsu.no-ip.org/dox/hal/classMotionHook.html
          >
          > The MotionHook::motionCheck() is your sugar daddy. That will be
          > called by the framework whenever new joint positions have been
          > calculated. So if your driver is created (from HAL command line: new
          > YourDriver [optional-name]) then it will immediately start receiving
          > joint values. You may prefer to override motionUpdated(), which is
          > called by the default motionCheck() implementation with only those
          > joints which have changed since last update.
          >
          > I might recommend looking at the SSC32 driver too, I'm not sure if
          > that is closer to the KHR2 interface. (if there's some documentation
          > for the KHR2 interface, I could skim it and give you more specific
          > advice.)
          >
          > As a heads up, the CommPort system is helpful for flexible execution.
          > For example, if you wish to run off-board for quicker development
          > turnaround, you could use a NetworkCommPort and stream your KHR2
          > commands over the network. But then for onboard execution you would
          > use (assuming) a SerialCommPort instead. (If I'm right about the
          > serial port usage, this also avoids you having to reimplement annoying
          > serial port configuration stuff) This is all done by the HAL, so your
          > driver just receives the generic CommPort interface, and the HAL
          > worries about creating and configuring it.
          >
          > Also, I just realized the DataSource documentation on that first link
          > is outdated... the LoadDataThread is gone, so if you write a
          > DataSource for sensors its up to your driver to push updates out when
          > available (i.e. might need your own thread), instead of having your
          > class polled for updates in the previous setup.
          >
          > -Ethan
          >
        • jtennys
          To revisit this topic, I am going to try to get something running for IROS in October. I put a cout statement to output the contents of the output array
          Message 4 of 6 , Sep 17, 2009
            To revisit this topic, I am going to try to get something running for IROS in October. I put a cout statement to output the contents of the "output" array into my driver file, but don't get any output when I run a motion control or edit postures. I might be thinking of the operation in a different way, but I thought that this motion update triggered each time a position was changed. Also, are the output floats just positions in radians, or something else?

            Jason Tennyson
          • Ethan Tira-Thompson
            ... MotionHook::motionCheck() is called at a regular rate (every RobotInfo::FrameTime*RobotInfo::NumFrames milliseconds), and the default per-MotionHook
            Message 5 of 6 , Sep 17, 2009

              I thought that this motion update triggered each time a position was changed

              MotionHook::motionCheck() is called at a regular rate (every RobotInfo::FrameTime*RobotInfo::NumFrames milliseconds), and the default per-MotionHook implementation is to call motionUpdated() with the changed outputs (or skip the call if nothing was updated).

              So if your function isn't being called, I would guess the MotionHook isn't being registered.  As a sanity check, might want to check if MotionHook::motionStarting is ever called.  I would check that your DeviceDriver has been created from the HAL command line (i.e. the tekkotsu command line prompt), and that this DeviceDriver returns your MotionHook from DeviceDriver::getMotionSink()...

              Also, are the output floats just positions in radians, or something else?

              Yes, for rotational joints this should be radians.  For prismatic joints it would be millimeters.  Similarly, for a wheel, we've been using millimeters per second at the rim.

              Good luck with the IROS submission, hopefully we can get you up and running soon :)

              -Ethan

            • Jason
              Thanks for the info, I hadn t been creating the driver.
              Message 6 of 6 , Sep 18, 2009
                Thanks for the info, I hadn't been creating the driver.

                --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
                >
                > > I thought that this motion update triggered each time a position was
                > > changed
                > >
                >
                > MotionHook::motionCheck() is called at a regular rate (every
                > RobotInfo::FrameTime*RobotInfo::NumFrames milliseconds), and the
                > default per-MotionHook implementation is to call motionUpdated() with
                > the changed outputs (or skip the call if nothing was updated).
                >
                > So if your function isn't being called, I would guess the MotionHook
                > isn't being registered. As a sanity check, might want to check if
                > MotionHook::motionStarting is ever called. I would check that your
                > DeviceDriver has been created from the HAL command line (i.e. the
                > tekkotsu command line prompt), and that this DeviceDriver returns your
                > MotionHook from DeviceDriver::getMotionSink()...
                >
                > > Also, are the output floats just positions in radians, or something
                > > else?
                > >
                >
                > Yes, for rotational joints this should be radians. For prismatic
                > joints it would be millimeters. Similarly, for a wheel, we've been
                > using millimeters per second at the rim.
                >
                > Good luck with the IROS submission, hopefully we can get you up and
                > running soon :)
                >
                > -Ethan
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.