Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#260 eeDHController

trunk
closed-fixed
Toby Collett
player (137)
4
2009-07-17
2008-12-30
Tobias Wilken
No

With the current svn version there are some problems, of the eeDHController

1. line 473 (server/drivers/limb/eeDHcontroller.cc). The third parameter is "PLAYER_LIMB_DATA", imho it should be "PLAYER_LIMB_DATA_STATE".

2. The case sensitivity. The Class is named EEDHController, but eeDHcontroller is used everywhere else. So I get compile problems with linux.

After fixing the compile problems I get a segmentation fault when I try to use it, I'm still searching for the solution.

A patch for the first two problems is applied.

Best regards
Tobias Wilken

Discussion

  • Tobias Wilken
    Tobias Wilken
    2008-12-30

    Patch for the "PLAYER_LIMB_DATA" and case sensitivity

     
    Attachments
  • Toby Collett
    Toby Collett
    2009-01-02

    I have made what I hope are equivalent changes to the driver, if you could grab the latest SVN trunk and give it a go. it should build, I wasn't able to identify anything obvious that would cause the segfault, could you attach a gdb backtrace.

     
  • Toby Collett
    Toby Collett
    2009-01-02

    • priority: 5 --> 4
    • assigned_to: gerkey --> thjc
     
  • Tobias Wilken
    Tobias Wilken
    2009-01-03

    Great, it compiles without errors now. The "segmentation fault" came from the shutdown method. I think you also fixed it.

    There are some more problems, ... The DHMatrixModel ist initialized with (6, 23). When I use a different number of joints than 6, it throws a "q has the wrong dimension in set_q()", it could also be initialized with (nr_joints, 23), I think it makes more sensse.

    And in the "loops" (AHomeLoop, ACmdLoop, ...). I don't know what the (p_state != c_state) is meant for, but it causes an endless loop. Shoudl I attach a patch for that?

    Another problem: Compiling brings an error with CvCAM, should i open a new ticket for that?

     
  • Toby Collett
    Toby Collett
    2009-01-04

    I have fixed up the nr_joints/matrix thing
    Are you able to provide a patch for the loops and detail about the CvCAM compile error?

     
  • Tobias Wilken
    Tobias Wilken
    2009-01-04

    Workaround for the "infinite-loop-problem"

     
    Attachments
  • Tobias Wilken
    Tobias Wilken
    2009-01-04

    Hey, you react really quick :-)

    My current solution for the "infinite loop" problem, is to comment out the (p_state != c_state) lines. I will attach the patch.

    I think this is only a workaround to get it working. Like I understand it, the actarray_state variable doesn't get updated, so p_state is everytime equal to c_state (equal 0).
    The problem is that the eeDHcontroller could switch to the next joint, while the first one is still moving (cause it doesn't get the correct state of the actarray). Until now, I didn't find a way to get the actarray_state varable correctly updated.

    Maybe it could be a problem of my enviroment, but I don't think so. I'm using gazebo for simulating an arm, player which only provides a simulation (gazebo), actarray(gazebo), limb(eeDHcontroller) interface. And a small client, which tries to move the arm to a position. If it is useful for you I can attach my configs.
    -----

    Another point is, I'm not really sure how to include the roboop library (in a fine way), which is used for the eeDHcontroller. I compiled it as shared library, copied it to the /usr/local/lib, copied the headers to /usr/local/include and added the line "LINK_LIBRARIES ("roboop" "newmat" )" to the CMakeList file in the player directory. I think this is a bad solution, but after try&test for some hours, this was the way, how I get it running. (I'm new to CMake) Maybe you could provide a better way, ...

    -----
    For the CvCAM problem I opened a new ticket.

    Best regards & thanks a lot
    Tobias Wilken
    File Added: eeDHcontroller.patch

     
  • Toby Collett
    Toby Collett
    2009-01-04

    • milestone: --> trunk
     
  • Toby Collett
    Toby Collett
    2009-01-04

    It is possible that the simulated actarray is not giving all of the information that is needed, alternatively it could be that the thread interactions in the driver are a little strange, there does not seem to be any mutexes to protect data access between the threads.

    It looks like it would be relatively easy to rewrite the driver to not use the threads. Just create a couple of extra state variables to track where it is up to in the command or home loops. I don't have time to look at this just now, but if you have a chance to and want to submit a patch that would be great.

     
  • Toby Collett
    Toby Collett
    2009-07-17

    • status: open --> closed-fixed
     
  • Toby Collett
    Toby Collett
    2009-07-17

    Initial problem is fixed, would be helpful to create new bug reports for the other issues if they are still causing problems.