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

Bicolormarkers demo and ERS7

Expand Messages
  • jayro91
    I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlane method of
    Message 1 of 10 , Jan 24, 2010
    View Source
    • 0 Attachment
      I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlane method of Kinematics.cc

      on line 220 (dir = invert(lowip.transpose())*ones;) throws an exception.

      The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.

      The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable." This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.

      I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.

      Any help or guidance would be greatly apprectiated.

      Thanks,
      Jason
    • Ethan Tira-Thompson
      Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it s
      Message 2 of 10 , Jan 24, 2010
      View Source
      • 0 Attachment
        Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it's just missing the infra-red rangefinder frames.

        -Ethan

        On Jan 24, 2010, at 11:37 PM, jayro91 wrote:

         

        I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlan e method of Kinematics.cc

        on line 220 (dir = invert(lowip. transpose( ))*ones;) throws an exception.

        The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.

        The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable. " This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.

        I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.

        Any help or guidance would be greatly apprectiated.

        Thanks,
        Jason


      • jayro91
        sweet! Thanks a million. It is up and running so now I get to see what I can make it do. Great timing on the update :) -Jason
        Message 3 of 10 , Jan 24, 2010
        View Source
        • 0 Attachment
          sweet!

          Thanks a million. It is up and running so now I get to see what I can make it do.

          Great timing on the update :)

          -Jason

          --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
          >
          > Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it's just missing the infra-red rangefinder frames.
          >
          > -Ethan
          >
          > On Jan 24, 2010, at 11:37 PM, jayro91 wrote:
          >
          > > I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlane method of Kinematics.cc
          > >
          > > on line 220 (dir = invert(lowip.transpose())*ones;) throws an exception.
          > >
          > > The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.
          > >
          > > The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable." This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.
          > >
          > > I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.
          > >
          > > Any help or guidance would be greatly apprectiated.
          > >
          > > Thanks,
          > > Jason
          > >
          > >
          >
        • jayro91
          Having trouble with the kinematics on the ERS-7. Scenario: I load the walk.pos file with some neck values added. tilt =0 pan =0 nod=.12 I start the
          Message 4 of 10 , Jan 31, 2010
          View Source
          • 0 Attachment
            Having trouble with the kinematics on the ERS-7.

            Scenario:
            I load the walk.pos file with some neck values added.
            tilt =0 pan =0 nod=.12

            I start the bicolormarkers demo and get some interesting results.
            The kine->calculateGroundPlane returns a displacement of 17 instead of something closer to 170. I have tried hardcoding but still get odd results. When I have the dogs head pointing straight the mapbuilder always thinks the object is well to its left even when I place the marker well to the right or straight in front of it. I have tried different marker heights just to test but this seems to have little effect. Any help or guidance on how to correct this would be greatly appreciated.

            Thanks,
            Jason

            --- In tekkotsu_dev@yahoogroups.com, "jayro91" <jayro7@...> wrote:
            >
            >
            > sweet!
            >
            > Thanks a million. It is up and running so now I get to see what I can make it do.
            >
            > Great timing on the update :)
            >
            > -Jason
            >
            > --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@> wrote:
            > >
            > > Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it's just missing the infra-red rangefinder frames.
            > >
            > > -Ethan
            > >
            > > On Jan 24, 2010, at 11:37 PM, jayro91 wrote:
            > >
            > > > I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlane method of Kinematics.cc
            > > >
            > > > on line 220 (dir = invert(lowip.transpose())*ones;) throws an exception.
            > > >
            > > > The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.
            > > >
            > > > The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable." This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.
            > > >
            > > > I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.
            > > >
            > > > Any help or guidance would be greatly apprectiated.
            > > >
            > > > Thanks,
            > > > Jason
            > > >
            > > >
            > >
            >
          • Ethan Tira-Thompson
            Sorry for the delay, I don t have any immediate ideas what might be wrong. I d say investigate what is returned for the ground plane and the camera ray.... see
            Message 5 of 10 , Feb 2, 2010
            View Source
            • 0 Attachment
              Sorry for the delay, I don't have any immediate ideas what might be wrong.

              I'd say investigate what is returned for the ground plane and the camera ray.... see if we can narrow the problem down to a bad estimate of the ground, an error in the head kinematics, or an error in the projection math...

              -Ethan

              On Jan 31, 2010, at 10:41 PM, jayro91 wrote:

               


              Having trouble with the kinematics on the ERS-7.

              Scenario:
              I load the walk.pos file with some neck values added.
              tilt =0 pan =0 nod=.12

              I start the bicolormarkers demo and get some interesting results.
              The kine->calculateGrou ndPlane returns a displacement of 17 instead of something closer to 170. I have tried hardcoding but still get odd results. When I have the dogs head pointing straight the mapbuilder always thinks the object is well to its left even when I place the marker well to the right or straight in front of it. I have tried different marker heights just to test but this seems to have little effect. Any help or guidance on how to correct this would be greatly appreciated.

              Thanks,
              Jason

              --- In tekkotsu_dev@ yahoogroups. com, "jayro91" <jayro7@...> wrote:
              >
              >
              > sweet!
              >
              > Thanks a million. It is up and running so now I get to see what I can make it do.
              >
              > Great timing on the update :)
              >
              > -Jason
              >
              > --- In tekkotsu_dev@ yahoogroups. com, Ethan Tira-Thompson <ejt@> wrote:
              > >
              > > Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it's just missing the infra-red rangefinder frames.
              > >
              > > -Ethan
              > >
              > > On Jan 24, 2010, at 11:37 PM, jayro91 wrote:
              > >
              > > > I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlan e method of Kinematics.cc
              > > >
              > > > on line 220 (dir = invert(lowip. transpose( ))*ones;) throws an exception.
              > > >
              > > > The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.
              > > >
              > > > The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable. " This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.
              > > >
              > > > I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.
              > > >
              > > > Any help or guidance would be greatly apprectiated.
              > > >
              > > > Thanks,
              > > > Jason
              > > >
              > > >
              > >
              >


            • jayro91
              Okay, here is some data I pulled out. I am using the walk.pos to set the posture of the robot with the same head info mentioned in the email before. I run the
              Message 6 of 10 , Feb 3, 2010
              View Source
              • 0 Attachment
                Okay, here is some data I pulled out. I am using the walk.pos to set the posture of the robot with the same head info mentioned in the email before. I run the bicolormakers demo.

                In the MarkerData.cc file calculateCameraDistance function:

                kine->calculateGroundPlane()
                In the calculateGroundPlane function the kinematics returned the following heights for the paws "Ground plane initial: paw2(370.463) paw0(-302.858) paw1(-302.858)" These values remained unchanged after checking for interest points.

                The function eventually returned the following plane equation. [0.269906 -0.421725 0.86562]@ = 18.576.

                If I am interpreting this correctly it is saying the distance between the ground and the camera is 18mm (Clearly not the case)
                There does not seem to be a whole lot of variables in play with the function as it is mainly using joint info. (Unless this joint info is not getting loaded correctly. I am not sure on that)

                Another thing I am not sure about is the camToBase transformation.
                kine->jointToBase(CameraFrameOffset) returns the following matrix:
                [0.55037 -0.250241 0.796538 130.307
                -0.816064 0.040382 0.576549 52.6825
                -0.176443 -0.967341 -0.181988 73.1131]

                The projections just break down from there without the initial ground plane calculation working. (Let me know where I am reading things wrong because that could be a high probability.)

                Let me know if any of that does not makes sense or is not helpful.

                Thanks for the assistance. I really appreciate it.

                - Jason



                --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
                >
                > Sorry for the delay, I don't have any immediate ideas what might be wrong.
                >
                > I'd say investigate what is returned for the ground plane and the camera ray.... see if we can narrow the problem down to a bad estimate of the ground, an error in the head kinematics, or an error in the projection math...
                >
                > -Ethan
                >
                > On Jan 31, 2010, at 10:41 PM, jayro91 wrote:
                >
                > >
                > > Having trouble with the kinematics on the ERS-7.
                > >
                > > Scenario:
                > > I load the walk.pos file with some neck values added.
                > > tilt =0 pan =0 nod=.12
                > >
                > > I start the bicolormarkers demo and get some interesting results.
                > > The kine->calculateGroundPlane returns a displacement of 17 instead of something closer to 170. I have tried hardcoding but still get odd results. When I have the dogs head pointing straight the mapbuilder always thinks the object is well to its left even when I place the marker well to the right or straight in front of it. I have tried different marker heights just to test but this seems to have little effect. Any help or guidance on how to correct this would be greatly appreciated.
                > >
                > > Thanks,
                > > Jason
                > >
                > > --- In tekkotsu_dev@yahoogroups.com, "jayro91" <jayro7@> wrote:
                > > >
                > > >
                > > > sweet!
                > > >
                > > > Thanks a million. It is up and running so now I get to see what I can make it do.
                > > >
                > > > Great timing on the update :)
                > > >
                > > > -Jason
                > > >
                > > > --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@> wrote:
                > > > >
                > > > > Try updating again, I was actually recently updating the Aibo kinematics for the new format, it might actually be working for what you need... I think it's just missing the infra-red rangefinder frames.
                > > > >
                > > > > -Ethan
                > > > >
                > > > > On Jan 24, 2010, at 11:37 PM, jayro91 wrote:
                > > > >
                > > > > > I am running the bleeding edge on an ERS-7 and having trouble getting the bicolormarkers demo to run. It blows up in the calculateGroundPlane method of Kinematics.cc
                > > > > >
                > > > > > on line 220 (dir = invert(lowip.transpose())*ones;) throws an exception.
                > > > > >
                > > > > > The problem appears to be in the kinematics.cc init() function where it tries to load a kin file.
                > > > > >
                > > > > > The following error is thrown: "Could not load ERS-7.kin forward and inverse kinematics unavailable." This causes the jointMaps KinematicJoint array to not be populated which is what I assume is causing the exception above.
                > > > > >
                > > > > > I am not sure where to get the kin file from or what it should be using. I see the old kin file that was removed during the roboop excise but nothing in the new plist xml format for an ERS7.
                > > > > >
                > > > > > Any help or guidance would be greatly apprectiated.
                > > > > >
                > > > > > Thanks,
                > > > > > Jason
                > > > > >
                > > > > >
                > > > >
                > > >
                > >
                > >
                >
              • Ethan Tira-Thompson
                ... These are not unreasonable... the heights are scaled by the length of the down vector, which on the Aibo comes from the accelerometer readings, so the
                Message 7 of 10 , Feb 5, 2010
                View Source
                • 0 Attachment
                  > In the MarkerData.cc file calculateCameraDistance function:
                  >
                  > kine->calculateGroundPlane()
                  > In the calculateGroundPlane function the kinematics returned the following heights for the paws "Ground plane initial: paw2(370.463) paw0(-302.858) paw1(-302.858)" These values remained unchanged after checking for interest points.

                  These are not unreasonable... the heights are scaled by the length of the "down" vector, which on the Aibo comes from the accelerometer readings, so the absolute value of these is not directly important, it's just using it to sort which legs are the furthest "down". It looks about right — the front paws are even, and usually the back leg is more stretched out in walking posture, so that's fits too.

                  > The function eventually returned the following plane equation. [0.269906 -0.421725 0.86562]@ = 18.576.

                  This does look strange though. Z should be the primary factor. Some trade-off with X makes sense, usually the walk leans forward a little. But there's a big Y component here, that indicates it thinks the robot is leaning heavily to one side (left/right), which is probably not correct.

                  Also, the way this is interpreted as relative to the center of the body. I'm not sure the if the sign on the last component should be positive or negative relative to the sign on the Z component, but this indicates a ground plane whose normal is 18mm from the center of the body, which also does not seem plausible.

                  > Another thing I am not sure about is the camToBase transformation.
                  > kine->jointToBase(CameraFrameOffset) returns the following matrix:
                  > [0.55037 -0.250241 0.796538 130.307
                  > -0.816064 0.040382 0.576549 52.6825
                  > -0.176443 -0.967341 -0.181988 73.1131]

                  This indicates the camera is looking a little down front-left, which doesn't match what you're expecting for the joint angles you specified before (tilt=0 pan=0 nod=.12)

                  So yeah, that's two things which don't really make sense, I will have to do some testing to see if I can replicate it. The rewritten kinematics file is new and not well tested, so it may be there are some mistakes in there.

                  -Ethan
                • jayro91
                  thanks for the explanation and details. I will keep on looking at it on my end but any help you could provide would be greatly appreciated. thanks, Jason
                  Message 8 of 10 , Feb 5, 2010
                  View Source
                  • 0 Attachment
                    thanks for the explanation and details.
                    I will keep on looking at it on my end but any help you could provide would be greatly appreciated.

                    thanks,
                    Jason


                    --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
                    >
                    > > In the MarkerData.cc file calculateCameraDistance function:
                    > >
                    > > kine->calculateGroundPlane()
                    > > In the calculateGroundPlane function the kinematics returned the following heights for the paws "Ground plane initial: paw2(370.463) paw0(-302.858) paw1(-302.858)" These values remained unchanged after checking for interest points.
                    >
                    > These are not unreasonable... the heights are scaled by the length of the "down" vector, which on the Aibo comes from the accelerometer readings, so the absolute value of these is not directly important, it's just using it to sort which legs are the furthest "down". It looks about right — the front paws are even, and usually the back leg is more stretched out in walking posture, so that's fits too.
                    >
                    > > The function eventually returned the following plane equation. [0.269906 -0.421725 0.86562]@ = 18.576.
                    >
                    > This does look strange though. Z should be the primary factor. Some trade-off with X makes sense, usually the walk leans forward a little. But there's a big Y component here, that indicates it thinks the robot is leaning heavily to one side (left/right), which is probably not correct.
                    >
                    > Also, the way this is interpreted as relative to the center of the body. I'm not sure the if the sign on the last component should be positive or negative relative to the sign on the Z component, but this indicates a ground plane whose normal is 18mm from the center of the body, which also does not seem plausible.
                    >
                    > > Another thing I am not sure about is the camToBase transformation.
                    > > kine->jointToBase(CameraFrameOffset) returns the following matrix:
                    > > [0.55037 -0.250241 0.796538 130.307
                    > > -0.816064 0.040382 0.576549 52.6825
                    > > -0.176443 -0.967341 -0.181988 73.1131]
                    >
                    > This indicates the camera is looking a little down front-left, which doesn't match what you're expecting for the joint angles you specified before (tilt=0 pan=0 nod=.12)
                    >
                    > So yeah, that's two things which don't really make sense, I will have to do some testing to see if I can replicate it. The rewritten kinematics file is new and not well tested, so it may be there are some mistakes in there.
                    >
                    > -Ethan
                    >
                  • Ethan Tira-Thompson
                    I just discovered a subtle but serious bug in KinematicJoint::getT(): http://www.tekkotsu.org/cvslog2web/2010/02/commit-1266284134.html This is hopefully the
                    Message 9 of 10 , Feb 15, 2010
                    View Source
                    • 0 Attachment
                      I just discovered a subtle but serious bug in KinematicJoint::getT():
                      http://www.tekkotsu.org/cvslog2web/2010/02/commit-1266284134.html

                      This is hopefully the cause of your trouble as well... basically anything converting from one kinematic branch to another was being miscalculated :(

                      Sorry for the inconvenience!

                      -Ethan
                    • jayro91
                      No luck on this change helping me. The makerdata code is calling the Point::projectToGround function which does not ever call kine- projectToPlane. I tried
                      Message 10 of 10 , Feb 18, 2010
                      View Source
                      • 0 Attachment
                        No luck on this change helping me.
                        The makerdata code is calling the Point::projectToGround function which does not ever call kine->projectToPlane. I tried changing this to call the other Point::projectToGround function which does call kine->projectToPlane but getT() exits before it reaches the new code you corrected. I have not been able to make any progress on my end on solving this kinematics mystery. (a mystery to me anyway) :(

                        Any help is greatly appreciated.

                        Thanks,
                        Jason

                        --- In tekkotsu_dev@yahoogroups.com, Ethan Tira-Thompson <ejt@...> wrote:
                        >
                        > I just discovered a subtle but serious bug in KinematicJoint::getT():
                        > http://www.tekkotsu.org/cvslog2web/2010/02/commit-1266284134.html
                        >
                        > This is hopefully the cause of your trouble as well... basically anything converting from one kinematic branch to another was being miscalculated :(
                        >
                        > Sorry for the inconvenience!
                        >
                        > -Ethan
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.