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
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!
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.
Related
Not sure how to word the title so feel free to rename, but the issue I'm having is that I've got a function that works in one project, but fails in another. Below is rough pseudocode to show that one call in LibraryProject works, whereas the call in GameProject doesn't.
In ChildClass::do_stuff, the win32_window HWND is valid, whereas the second one, failed_win32_window is null and glfw throws an error saying it isn't initialized, despite it already having been initialized (since the first glfw call was successful and I've manually stepped through to verify it was):
GLFWError #65537 Happen, The GLFW library is not initialized
Here's pseudocode showing the two projects, and the files. GLFW is set initialized properly since if I do all my glfw logic within LibraryProject, the window shows up as normal.
//LibraryProject
////library_header.h
class ParentClass {
GLFW* _mainWindow; //filled in elsewhere in the real code
HWND getWin32Window() { return glfwGetWin32Window(_mainWindow); }
}
//GameProject
////game_header.h
#include "library_header.h" //from other Project
class ChildClass : public ParentClass {
void do_stuff() {
HWND win32_window = this->getWin32Window(); //this works because it goes down into LibraryProject.dll's module
HWND failed_win32_window = glfwGetWin32Window(_mainWindow); //but literally the same call here doesn't because it happens within GameProject.exe
}
}
////game_body.cpp
void function_called_elsewhere_in_game() {
//called from GameProject.exe
auto child = ChildClass();
child.do_stuff();
}
I'm not sure if this is an issue with glfw and my setup, or just my misunderstanding how projects and dependencies work.
Things I've tried:
Downloading the latest glfw3
Rebuilding the entire solution
Toggling with References and Linking Dependency Inputs
Things to note:
This is happening in the main thread, nothing else is using glfw at the same time. Its 100% reproducible too.
glfw3.lib is always being created in my GameProject output folder, based on the one inside LibraryProject
Stepping through the disassembly for each of the two glfwGetWin32Window calls has different addresses in disassembly, leading me to believe they're two different copies of the same library, but I'm not sure.
This is not an issue with cocos2d, the game engine I'm using as starting a blank project and calling glfwGetWin32Window(..) returns a valid pointer, even in GameProject, so there's something that I'm doing wrong, but I don't know what.
Images showing off the actual behaviour. magnolia_cocos_proj is GameProject and is the exe I'm running, and libcocos2d is LibraryProject I'm using as a DLL (I'm unfamiliar with the details of how linking and dlls work).
win32_window has valid value
definition of getWin32Window() to be 100% sure. Notice the module is in libcocos2d.dll now.
after going over the second line, the error throws and the second window is null
As I understood from "glfw3.lib is always being created" you use static linking. Static linking of a lib to different dll and exe lead to duplicating of all static memory of the lib. You should use a dynamic library for GLFW in the case. It's glfw3dll.lib.
There are two main cases why this error could appear:
GLFWError #65537 Happen, The GLFW library is not initialised
Case One :
The mentioned error occurs if a GLFW function was called that mustn't be called unless the library is initialised. So, you need to initialise GLFW before calling any function that requires initialisation.
Read an API introduction for reference. Use if-else statement for handling glfwInit() and errors.
Reading Moving from GLFW 2 to 3 is also useful.
Case Two :
This error quite often occurs in the case you have previous versions of GLFW installed on your machine. GLFW3 doesn't like running along with previous version installed. So, delete all the GLFW libraries and linkers and reinstall the latest GLFW 3 from scratch.
Hope this helps.
I'm using a physics library called Chipmunk(version 7.0.1) for a game engine in Pharo Smalltalk(version 6).
I initialize a Space with a call to function "cpSpaceNew()" and i´m correctly getting the pointer to cpSpace structure. Then i want to set the gravity to the space using a call to function "cpSpaceSetGravity(space, gravity)" and i get a Segmentation Fault.
I found a similar question : Segmentation fault on library call
but it is old question and did not find solution there.
EDIT:
Getting cpSpace pointer with:
^ self ffiCall: #( cpSpace* cpSpaceNew(void) )
"ffical:" is native call from Smalltalk.
Trying to set the gravity with:
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
options: #( optIndirectCall );
function: #(void cpSpaceSetGravity (self , cpVect aVector)) module: self ffiLibraryName
This way of function call is because it is an "inline function" and it is not load in Library.
Which gcc version are you using? I recommend using older or maybe ancient one.
Excerpt from Pharo mailing list:
My understanding is that gcc 4.8(.4) is the default version in trusty,
so if anyone else wants to build the VM with the same compiler,
they'll need gcc 4.8.
At the moment it is needed because a few people have found that the VM
doesn't work properly if compiled with gcc 5.4
Good afternoon.
I'm using Veins v4.4 and Sumo 0.25 with Omnet++ v4.6.
I was trying to get information about brakes and blinkers: I've found the VehicleSignal field in TraCISCenarioManager.h and the getSignals() method in TraCIMobility.h , but as soon as I call this function in my code, it runs in exception since I suppose the variable is never updated. Shouldn't it be updated runtime from Sumo?
Thanks for helping
You found some functionality that was never fully implemented in Veins 4.4. As a quick hack, you can make this work by changing line 891 of TraCIScenarioManager.cc to also update each vehicle's signal field, e.g., as follows:
mm->nextPosition(p, edge, speed, angle, VehicleSignal(signals));
I have read this blogpost http://www.ics.com/blog/qt-tips-and-tricks-part-1 and tried to enable plugin debugging as described.
I've put this line in my main.cpp:
qputenv(QT_DEBUG_PLUGINS, 1);
But if I try to compile I'm getting this error:
.../src/main.cpp:14: error: 'QT_DEBUG_PLUGINS' was not declared in this scope
qputenv(QT_DEBUG_PLUGINS, -1);
What is the problem here and how do I have to do it right?
qputenv("QT_DEBUG_PLUGINS", QByteArray("1"));
But I don't get any additional output.
I'm using Qt5.5.1 with QtCreator 3.6 under KUbuntu 15.10.
You're supposed to set env variable from outside your program, not from inside! It's very likely the plugin loading you're interested into already happened by the time you reach that line. Try putting it before creating a Q*Application object.
– peppe
That's it. It was definitely set before plugin loading, but it seems to be important to set it before creating Q*Application as you wrote. Thank you.
– avb
I am currently using TGUI (a GUI library based on SFML) together with ECL (so I can use Lisp for config and scripts). It works fine on Linux/gcc, but on Windows/MinGW ECL throws an error:
Condition of type: FLOATING-POINT-INVALID-OPERATION
#<a FLOATING-POINT-INVALID-OPERATION>
Available restarts:
1. (CONTINUE) Ignore signal
Top level in: #<process TOP-LEVEL>.
>
The point in code at which the error is thrown (minimal code that creates it) is:
empty_panel = tgui::Panel::Ptr(*cur_gui, "empty_panel");
empty_panel->setSize(cfg.res.x, cfg.res.y);
empty_panel->setBackgroundColor(sf::Color::Transparent);
tgui::EditBox::Ptr txt_test(*empty_panel, "txt_test");
Note that I can create Labels, Buttons, Checkboxes, etc. just fine - but once I try to make an Edit Box, ECL complains.
This does not make any sense to me whatsoever. TGUI and ECL are completely unrelated libraries, not sharing functions or depending on each other in any way that I know of. Does anyone have an idea what might cause this behavior?
EDIT: Just did a complete recompile of SFML, TGUI and ECL with the most recent version of MinGW, and it still breaks in exactly the same way. So I've decided that enough is enough and I'll rewrite my project to use SFGUI instead.
From now on, this question is of academic interest only.
I finally found out what might have happened there:
While ECL is running, it tries to handle all uncaught exceptions, segfaults, etc that happen on it's watch, even if they never interact with LISP. And the way it handles them is by immediately jumping to the REPL when they occur, to allow for manual debugging.
Which is the sane thing to do for anything that happens because of errors in a LISP program or C/C++ functions that interact with it, but is mildly confusing when the error happens in unrelated C++ code (like the presumed bug in TGUI).
Minimal way to reproduce: Load ECL and try some invalid operation, like so:
#include <ecl/ecl.h>
int main(int argc, char **argv) {
cl_boot(argc, argv);
atexit(cl_shutdown);
int x = 1/0;
return EXIT_SUCCESS; }