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

Re: KHR2 Head Controller

Expand Messages
  • Aaron
    I don t mean to repost my questions but this is an issue we would like to address. Do you know of the cause of this error we are getting?
    Message 1 of 8 , Feb 9, 2011
    • 0 Attachment
      I don't mean to repost my questions but this is an issue we would like to address. Do you know of the cause of this error we are getting?

      --- In tekkotsu_dev@yahoogroups.com, "Aaron" <aaparke@...> wrote:
      >
      > We have been toying with walking parameters and getting the robot to physically walk for a few weeks now but we are making little progress. The bottom of the SkewlZone feet we are using are made of rubber for extra grip which seems like a good thing, however, unless the foot comes down perfectly level with the floor every cycle problems occur.
      >
      > The simulator can assume perfect servo positions, which is why the foot allways appears level in the simulator, however actual servos are quite a bit more messy than that. Usually what happens is a toe comes down first and catches on the ground which causes the robot to trip over itself.
      >
      > Jason and I have thought of a possible solution, implement the balancing behavior first and run it along side the walk behavior. A passive balancing behavior would theoretically level the feet and cause a more stable walk. Our thoughts on making this behavior are currently set on just having the motion manager merge servo positions from both the balance behavior and the walk behavior at once, for simplicity.
      >
      > At the moment, the only way to get sensor data from the controller onboard the khr2 is through the onboard gumstix running a proxy which forwards messages from the skewlzone driver to the rcb3 (embedded khr2 servo controller). This has worked for us before and requires just a few different lines of code in the skewlzonedriver.h file to work over wifi.
      >
      > Using a desktop as the tekkotsu host (still havn't cross compiled tekkotsu) we ssh into the gumstix, start the proxy, run tekkotsu on the desktop and operate the khr2. We have gotten sensor data and driven motors in this way before using tekkotsu, but recently we got the following error.
      >
      > Tekkotsu Robotics Framework 5.03-CVS, libtekkotsu compiled on Jan 27 2011 at 15:26:33
      > Found a Mary text-to-speech server.
      > E Stop Applied to SkewlZone!
      > SkewlZoneDriver "KHR2": could not find CommPort ""
      > Trying 1280x960
      > Trying 640x480
      > Image will be upsampled to 640x480.
      > HAL:KHR2> *** ERROR Simulator: Received SIGSEGV
      > 0 sim::handle_signal(int) +0x301 (usr/local/Tekkotsu/local/tekkotsu/sim.cc:587)
      > 1 __kernel_sigreturn +0 (0xf76f0400, offset 0xf76f0000 in unknown lib)
      > 2 __dynamic_cast +0x1c (libstdc++.so.6)
      > 3 plist::ArrayOf<plist::Primitive<int>, plist::ArrayBase::ConversionTo<plist::Primitive<int> > >::operator[](unsigned int) const +0x4d (libtekkotsu.so) (usr/local/Tekkotsu/Shared/plistCollections.h:1302)
      > 4 SkewlZoneDriver::advance() +0x1a1 (libtekkotsu.so) (usr/local/Tekkotsu/local/DeviceDrivers/SkewlZoneDriver.cc:185)
      > 5 CallbackPollThread::FunctorInstance<bool (SkewlZoneDriver::*)(), SkewlZoneDriver, (CallbackPollThread::ReturnHandle_t)0>::operator()() +0x4e (libtekkotsu.so) (usr/local/Tekkotsu/IPC/CallbackThread.h:235)
      > 6 CallbackPollThread::poll() +0x1e (usr/local/Tekkotsu/IPC/CallbackThread.h:255)
      > 7 PollThread::run() +0x2ba (libtekkotsu.so) (usr/local/Tekkotsu/IPC/PollThread.cc:59)
      > 8 Thread::launch(void*) +0x2ef (libtekkotsu.so) (usr/local/Tekkotsu/IPC/Thread.cc:322)
      > 9 start_thread (libpthread.so.0)
      > 10 clone +0x5e (libc.so.6)
      > *** ERROR Simulator: Engaging fault shutdown...
      > *** ERROR Simulator: Dereferencing message queue SemaphoreManager
      > *** ERROR Simulator: Exiting...
      >
      > So this is just a long winded and informative way of asking, any idea what this is about?
      >
      > --Aaron
      >
      >
      > --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@> wrote:
      > >
      > > > For non-leg joints, is it intended that setting a frequency scale of 0.0 means the joint will simply move to that position and remain there, not oscillating?
      > >
      > > Yes, that is correct. So `1' does one cycle per gait cycle, `2' does two cycles, and `0' holds constant. I think the frequency scale only really makes sense for integer values btw... with a fractional value the beginning and end of the cycle won't match up so you'll get a sudden `twitch' at the seam.
      > >
      > >
      > > > Is there a way to offset the oscillation? We came about this from needing the arms spread out from the body to avoid self collisions and servo damage.
      > >
      > > Hmm, a good point, this is missing. If you use FreqScale=0, you can use Magnitude to control a constant position when walking, but currently there's no parameter to provide an offset with an oscillation.
      > >
      > > This is not hard to add however. I've just checked in a new `Baseline' parameter that should do this.
      > > http://cvs.tekkotsu.org/viewvc/Tekkotsu/Motion/XWalkMC.h?r1=1.62&r2=1.63
      > >
      > >
      > > > The stance width set's how far along the x axis the foot is placed relative to the base frame, and the stride bias does the same along the y axis, what does stride margin do?
      > >
      > > I think it's the other way? Assuming the robot faces `forward' along positive x, the stance width would be along y and stride bias would be along x. StrideMargin is ignored, that was planned for automatic calculation of the stride length, but never materialized, I should remove it.
      > >
      > >
      > > > Our end goal is to create a walking behavior which self balances while walking using 6 pressure sensors on each foot and the accelerometer. Does the motion manager merge motion outputs together? Say if we let the xwalk behavior run, but through another behavior adjusted the ankle positions to balance the robot, would the two output positions be merged together or would one override the other?
      > >
      > > Yes the motion manager does merge motions. The method it uses is analogous to a graphics editor: each motion command has a priority level, similar to `layers' in the image editor. Higher priorities are on top of the stack, so they mask output values from commands lower in the stack.
      > >
      > > However, each output value has a weight, similar to an alpha or opaqueness value per pixel in the image editor. So weights below 1 become more transparent, and allow a lower priority to show through. For example, weight=0 (or equivalently not specifying a value for that output at all) allows lower priority commands to have free use of that output.
      > >
      > > One aspect where the graphics analogy breaks down is that motion commands can have identical priority levels, whereas the image editor always has a strict ordering of its layers. The motion manager will simply do a weighted average of commands at the same priority, and if the total weight is still less than 1, then lower levels make up the difference.
      > >
      > > In case you are wondering, the 'transparency' aspect is handy if you have a high priority motion cut in, do something, then it wants to `fade out', so that it doesn't just instantly snap back to whatever the lower priority motion was doing.
      > >
      > > In practice, we haven't needed to use this feature much, but it could be useful for your balancing routine — a high priority motion command with half-weight which tweaks ankle values or such. This could be tricky though, your tweaks will only have half influence if a walk is running, but full influence if nothing else is running. You could just fully override the ankles, but I don't know if that would be enough. It's a cute idea for a quick test, but I think this will be troublesome to fully implement.
      > >
      > > The alternative approach, perhaps a bit more conventional, would be to subclass XWalk (e.g. `BipedalWalk') and do your balance routine on top of that. You could make life easier by adding a hook near the end of the XWalk updateOutputs pathway, say 'updateBalance()' or such, which is a no-op in XWalk, but is overridden in BipedalWalk to tweak the ankles or whatever you need in response to the sensors.
      > >
      > > -Ethan
      > >
      >
    • Ethan Tira-Thompson
      I’m guessing your SkewlZoneDriver.cc isn’t quite the same as the last version I have in the bug tracker since line 185 doesn’t seem to make sense for
      Message 2 of 8 , Feb 9, 2011
      • 0 Attachment
        I’m guessing your SkewlZoneDriver.cc isn’t quite the same as the last version I have in the bug tracker since line 185 doesn’t seem to make sense for calling any plist stuff shown in the stack trace.
        http://bugs.tekkotsu.org/attachment.cgi?id=38&action=edit

        But judging by the types, it’s a bad access to inputs[]. One way I could see this going wrong in the current code is if the driver configuration file loads an array from the file, and that array is too short, it will resize the array in memory and then your for loops will go out of bounds.

        To prevent this possibility, append a ‘false’ argument to your plist::Array constructors. This will mark them non-resizeable, so loading from a configuration file can’t cause an error. Specifically, in SkewlZoneDriver.h, do this:

        servos(NUM_SERVO,UNUSED,false), inputs(NUM_INPUT,UNUSED,false),
        minPW(NUM_SERVO,500,false), maxPW(NUM_SERVO,2500,false),
        buttonMode(NUM_INPUT,false,false),

        As for the foot/balance stuff, you could certainly use an independent motion command and have it tweak ankle values to be merged by the motion manager. Running this offboard via wifi might be a little tricky due to increased latency, e.g. watch out for resonant feedback...

        Alternatively, if the common problem is the toe catching, you might tweak the walk so it does a bit of heel-toe action: instead of keeping the foot level, purposely tilt it so the heel will strike first, and level the foot out as it descends. It might be interesting to tilt it on pickup as well to give a push-off.

        -Ethan

        On Feb 9, 2011, at 3:20 PM, Aaron wrote:

        > I don't mean to repost my questions but this is an issue we would like to address. Do you know of the cause of this error we are getting?
        >
        > --- In tekkotsu_dev@yahoogroups.com, "Aaron" <aaparke@...> wrote:
        > >
        > > We have been toying with walking parameters and getting the robot to physically walk for a few weeks now but we are making little progress. The bottom of the SkewlZone feet we are using are made of rubber for extra grip which seems like a good thing, however, unless the foot comes down perfectly level with the floor every cycle problems occur.
        > >
        > > The simulator can assume perfect servo positions, which is why the foot allways appears level in the simulator, however actual servos are quite a bit more messy than that. Usually what happens is a toe comes down first and catches on the ground which causes the robot to trip over itself.
        > >
        > > Jason and I have thought of a possible solution, implement the balancing behavior first and run it along side the walk behavior. A passive balancing behavior would theoretically level the feet and cause a more stable walk. Our thoughts on making this behavior are currently set on just having the motion manager merge servo positions from both the balance behavior and the walk behavior at once, for simplicity.
        > >
        > > At the moment, the only way to get sensor data from the controller onboard the khr2 is through the onboard gumstix running a proxy which forwards messages from the skewlzone driver to the rcb3 (embedded khr2 servo controller). This has worked for us before and requires just a few different lines of code in the skewlzonedriver.h file to work over wifi.
        > >
        > > Using a desktop as the tekkotsu host (still havn't cross compiled tekkotsu) we ssh into the gumstix, start the proxy, run tekkotsu on the desktop and operate the khr2. We have gotten sensor data and driven motors in this way before using tekkotsu, but recently we got the following error.
        > >
        > > Tekkotsu Robotics Framework 5.03-CVS, libtekkotsu compiled on Jan 27 2011 at 15:26:33
        > > Found a Mary text-to-speech server.
        > > E Stop Applied to SkewlZone!
        > > SkewlZoneDriver "KHR2": could not find CommPort ""
        > > Trying 1280x960
        > > Trying 640x480
        > > Image will be upsampled to 640x480.
        > > HAL:KHR2> *** ERROR Simulator: Received SIGSEGV
        > > 0 sim::handle_signal(int) +0x301 (usr/local/Tekkotsu/local/tekkotsu/sim.cc:587)
        > > 1 __kernel_sigreturn +0 (0xf76f0400, offset 0xf76f0000 in unknown lib)
        > > 2 __dynamic_cast +0x1c (libstdc++.so.6)
        > > 3 plist::ArrayOf<plist::Primitive<int>, plist::ArrayBase::ConversionTo<plist::Primitive<int> > >::operator[](unsigned int) const +0x4d (libtekkotsu.so) (usr/local/Tekkotsu/Shared/plistCollections.h:1302)
        > > 4 SkewlZoneDriver::advance() +0x1a1 (libtekkotsu.so) (usr/local/Tekkotsu/local/DeviceDrivers/SkewlZoneDriver.cc:185)
        > > 5 CallbackPollThread::FunctorInstance<bool (SkewlZoneDriver::*)(), SkewlZoneDriver, (CallbackPollThread::ReturnHandle_t)0>::operator()() +0x4e (libtekkotsu.so) (usr/local/Tekkotsu/IPC/CallbackThread.h:235)
        > > 6 CallbackPollThread::poll() +0x1e (usr/local/Tekkotsu/IPC/CallbackThread.h:255)
        > > 7 PollThread::run() +0x2ba (libtekkotsu.so) (usr/local/Tekkotsu/IPC/PollThread.cc:59)
        > > 8 Thread::launch(void*) +0x2ef (libtekkotsu.so) (usr/local/Tekkotsu/IPC/Thread.cc:322)
        > > 9 start_thread (libpthread.so.0)
        > > 10 clone +0x5e (libc.so.6)
        > > *** ERROR Simulator: Engaging fault shutdown...
        > > *** ERROR Simulator: Dereferencing message queue SemaphoreManager
        > > *** ERROR Simulator: Exiting...
        > >
        > > So this is just a long winded and informative way of asking, any idea what this is about?
        > >
        > > --Aaron
        > >
        > >
        > > --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@> wrote:
        > > >
        > > > > For non-leg joints, is it intended that setting a frequency scale of 0.0 means the joint will simply move to that position and remain there, not oscillating?
        > > >
        > > > Yes, that is correct. So `1' does one cycle per gait cycle, `2' does two cycles, and `0' holds constant. I think the frequency scale only really makes sense for integer values btw... with a fractional value the beginning and end of the cycle won't match up so you'll get a sudden `twitch' at the seam.
        > > >
        > > >
        > > > > Is there a way to offset the oscillation? We came about this from needing the arms spread out from the body to avoid self collisions and servo damage.
        > > >
        > > > Hmm, a good point, this is missing. If you use FreqScale=0, you can use Magnitude to control a constant position when walking, but currently there's no parameter to provide an offset with an oscillation.
        > > >
        > > > This is not hard to add however. I've just checked in a new `Baseline' parameter that should do this.
        > > > http://cvs.tekkotsu.org/viewvc/Tekkotsu/Motion/XWalkMC.h?r1=1.62&r2=1.63
        > > >
        > > >
        > > > > The stance width set's how far along the x axis the foot is placed relative to the base frame, and the stride bias does the same along the y axis, what does stride margin do?
        > > >
        > > > I think it's the other way? Assuming the robot faces `forward' along positive x, the stance width would be along y and stride bias would be along x. StrideMargin is ignored, that was planned for automatic calculation of the stride length, but never materialized, I should remove it.
        > > >
        > > >
        > > > > Our end goal is to create a walking behavior which self balances while walking using 6 pressure sensors on each foot and the accelerometer. Does the motion manager merge motion outputs together? Say if we let the xwalk behavior run, but through another behavior adjusted the ankle positions to balance the robot, would the two output positions be merged together or would one override the other?
        > > >
        > > > Yes the motion manager does merge motions. The method it uses is analogous to a graphics editor: each motion command has a priority level, similar to `layers' in the image editor. Higher priorities are on top of the stack, so they mask output values from commands lower in the stack.
        > > >
        > > > However, each output value has a weight, similar to an alpha or opaqueness value per pixel in the image editor. So weights below 1 become more transparent, and allow a lower priority to show through. For example, weight=0 (or equivalently not specifying a value for that output at all) allows lower priority commands to have free use of that output.
        > > >
        > > > One aspect where the graphics analogy breaks down is that motion commands can have identical priority levels, whereas the image editor always has a strict ordering of its layers. The motion manager will simply do a weighted average of commands at the same priority, and if the total weight is still less than 1, then lower levels make up the difference.
        > > >
        > > > In case you are wondering, the 'transparency' aspect is handy if you have a high priority motion cut in, do something, then it wants to `fade out', so that it doesn't just instantly snap back to whatever the lower priority motion was doing.
        > > >
        > > > In practice, we haven't needed to use this feature much, but it could be useful for your balancing routine — a high priority motion command with half-weight which tweaks ankle values or such. This could be tricky though, your tweaks will only have half influence if a walk is running, but full influence if nothing else is running. You could just fully override the ankles, but I don't know if that would be enough. It's a cute idea for a quick test, but I think this will be troublesome to fully implement.
        > > >
        > > > The alternative approach, perhaps a bit more conventional, would be to subclass XWalk (e.g. `BipedalWalk') and do your balance routine on top of that. You could make life easier by adding a hook near the end of the XWalk updateOutputs pathway, say 'updateBalance()' or such, which is a no-op in XWalk, but is overridden in BipedalWalk to tweak the ankles or whatever you need in response to the sensors.
        > > >
        > > > -Ethan
        > > >
        > >
        >
        >
      • Aaron
        Ok, got it working again! Thanks for the tip on the bad index. Turns out we were using NumFootSensors instead of SensorsPerFoot for an offset. Got everything
        Message 3 of 8 , Feb 10, 2011
        • 0 Attachment
          Ok, got it working again! Thanks for the tip on the bad index. Turns out we were using NumFootSensors instead of SensorsPerFoot for an offset. Got everything working now. I'll upload all our updated info.h and skewlzone drivers soon.
        Your message has been successfully submitted and would be delivered to recipients shortly.