![]() While the controller is still in memory you can query the values of some variables in order to understand what happened. The line 106 of the source file "soccer_supervisor.c" must be examined closely. Therefore it seems that the problem is caused by an illegal use of the sprintf function in the run function. In this example we will assume that the sprintf function is OK, because it is in a system library. #0 0x00cd6dd5 in _IO_str_overflow_internal() from /lib/tls/libc.so.6 #1 0x00cd596f in _IO_default_xsputn_internal() from /lib/tls/libc.so.6 #2 0x00cca9c1 in _IO_padn_internal() from /lib/tls/libc.so.6 #3 0x00cb17ea in vfprintf() from /lib/tls/libc.so.6 #4 0x00ccb9cb in vsprintf() from /lib/tls/libc.so.6 #5 0x00cb8d4b in sprintf() from /lib/tls/libc.so.6 #6 0x08048972 in run(duration=0) at soccer_supervisor.c:106 #7 0x08048b0a in main() at soccer_supervisor.c:140īy examining carefully the call stack you can locate the source of the error. You must recompile the controller directly in a terminal, as the Webots text editor Build button will omit debugging information from the build: The first step is to recompile the controller with the debug target, in order to add debugging information to the executable file. On Windows GDB can be installed for example from the MSYS2 environment with the mingw-w64-x86_64-gdb package as indicated in the optional dependencies of the Windows installation instructions. The following example assumes that there is a problem with the "soccer_supervisor" controller and indicates how to proceed with the debugging. Note that the crash of a controller is almost certainly caused by an error in the controller code, because an error in Webots would have caused Webots to crash.įortunately, the GNU debugger ( gdb) can usually help finding the reason of the crash. In this example the "soccer_supervisor" has crashed. If one of your robot controllers is missing in the list (or appearing as defunct) this confirms that it has crashed and therefore blocked the simulation. On macOS, use rather ps -x and on Windows use the Task Manager for this. However, I think it would be better to disable collisions between my passive connector objects and the active connector gripper. A simple solution would be to further reduce the size of grippers bounding box. This can easily be confirmed by listing the active processes at this moment: For example on Linux, type: When decelerating, the gripper then collides with the object. So if you come across a situation where your simulation stops unexpectedly, but the Webots GUI is still responsive, this usually indicates that the controller has crashed. When a controller process performs an illegal instruction, it is terminated by the operating system while the Webots process and the other controller processes remain active.Īlthough Webots is still active, the simulation blocks because it waits for data from the terminated controller. To debug a C/C++ controller with Microsoft Visual Studio, please see here. In the Webots environment, the Webots application and each robot C/C++ controller are executed in distinct operating system processes.įor example, when the "soccer.wbt" world is executed, there is a total of eight processes in memory one for Webots, six for the six player robots, and one for the supervisor robot. Debugging C/C++ Controllers Controller Processes
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |