#260 eeDHController

trunk
closed-fixed
player (137)
4
2009-07-17
2008-12-30
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

     
  • 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"

     
  • 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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks