Why do I receive a SIGSEGV signal while using the Aria robotics API?

Question

I am using the Aria C++ programming libs for mobile robots (http://robots.mobilerobots.com/wiki/ARIA). I am new to this API so I wanted to start with a simple action class derived from ArAction. Now I tried to develop a small test program (an ArAction) in order to control a simulated p3dx robot via MobileSim. Development takes place under Ubuntu 10.10, using gcc 4.4.5. Making (compiling) my code works fine, without errors. I can also set the desired speed for example in my ArAction's fire() method, and the simulation is also working as desired.

But, unfortunately, I can't use the ArRobot object attached to the ArAction I am overriding. The problem is that none of the member functions of the ArRobot object seems to work. For example, calling getVel() or getCompass() always returns a zero value. And when I call the hasFrontBumpers() method the program even crashes with the error message "Aria: Received signal 'SIGSEGV'. Exiting.". As soon as I remove this method call and recompile the error is also gone again...

Here is the relevant code that leads to the crash:

ArActionDesired * forward::fire(ArActionDesired d)
{
  desiredState.reset();

  ArRobot *r = getRobot();
  if(r == NULL)
  {
    printf("ArRobot = NULL\n");
    deactivate();
    return &desiredState;
  }

  printf("ok, ArRobot is not NULL, check for bumpers...\n");
  r->hasFrontBumpers(); // <-- this leads to the SIGSEV-based "crash"

  return &desiredState;
}

Any ideas what I am missing here -- is it a problem with my coding, or with the simulation environment? Thanks in advance for your help!

Kind regards, Matthias

Answer 1

ok, found it out now -- for the records: the Aria libs in version 2.7.2 are based on gcc-3 and libstdc++ 5, but Ubuntu 10.10 (which I am using) is shipped with gcc-4 and libstdc++ 6 per default. So I had to manually install the older versions of both packages, now my code is running fine...

cheers!

Answer 2

Calling hasFrontBumpers() for a p3dx from the fire() works fine for me on a similar Linux platform. If something is wrong, it is not in this method but in the initialization of the system. A reason for the non-moving robot could be that robot.enableMotors() hasn't been called.