#WEBOTS LOGIN WINDOWS#
Native robot windows still exist in Webots. However, they will soon be ported to the HTML robot window.Īfter that, the native robot window system will be progressively phased out. The vehicle, Darwin-OP robot windows and BotStudio still use the native robot window (see below). If a Robot's controller is changed or restarted during the simulation run, the robot window associated to the same Robot node will be restarted as well. The HTML robot windows can communicate with controller programs written using any of the supported programming languages, i.e.
#WEBOTS LOGIN HOW TO#
How to change the title of the robot window from the controller program.How to send user interface events (like mouse clicks) from the robot window to the controller program.How to display sensor information in the robot window.They are web-ready and could be used to display robot windows on web pages.Ī simple example of an HTML robot window is provided in the robots/thymio/thymio2.wbt sample simulation and demonstrates:.The equivalent controller functions are wb_robot_wwi_receive_text and wb_robot_wwi_send_text. They communicate directly with the robot controller using two Javascript functions: webots.window("").receive and webots.window("").send.They rely on HTML layout and Javascript programming.Robot windows are implemented in HTML and provide the following features: The window field of the Robot node specifies a robot window. Robot windows can be opened by double-clicking on the virtual robot, or using the context menu.
LibRemoteControl -.-> RealRobotĪ robot window allows the programmer to efficiently create custom user interfaces for his robots. The search algorithm to convert the window and the remoteControl to an existing path is explained in the Reference Manual.Įach distributed shared library is built thanks to the main Makefile (the same as the one used to build the controllers): This implies that if an entry point of a plugin is blocked, the controller will also be blocked.Īnd if the plugin crashes, the controller is also crashed. The controller plugin runs in the main thread of the process (also known as GUI thread): the same as the controller executable. The Robot node defines the location of the controller plugin through its window and its remoteControl fields. Some of these entry points are required and some are optional. However, it's certainly possible to write them in other languages using a C/C++ wrapper inbetween.Īfter its loading, some controller plugin functions (entry points) are called by libController.Ī set of entry points have to be defined to let the controller plugin work smoothly. The controller plugins have been designed to be written in C/C++, because the result should be a dynamic library. However, we recommend to respect them to get a good design. Of course these rules can be easily broken because every entity runs into the same process. This can be done via the libController API through the wb_robot_get_mode, wb_robot_set_mode and the wb_remote_control_custom_function functions. The only exception is about the robot window library which can be aware of the remote control library in order to initialize and monitor it. The controller should not be aware of its robot window and its real robot for modularity reasons.
The IPC between libRemoteControl and the real robot is defined by the user (TCP/IP, Serial, etc.).Īll the entities (the controller, the remote control library and the robot window library) should only call the libController interface (Webots API) functions. The IPC between libController and Webots is a pipe (On Windows this is a named pipe, and otherwise a local domain socket). In this figure, the dashed arrows shows how the shared libraries are loaded, and the large dash lines represents an Inter-Process Communication (IPC). The following figure shows an overview of the controller plugin system. Whatever its language, a controller executable is linked with the Webots controller library (libController) at startup.Ī controller plugin is a shared library loaded dynamically (at runtime) by libController after a specific event depending on its type. Programming controller plugins rather than programming directly in the controller is more convenient because it increases considerably the modularity and the scalability of the code.įor example a robot window can be used for several robots. The purpose of a controller plugin is to ease the programming of robot-specific robot windows and remote-control wrappers. The controller functionality can be extended with user-implemented plugins.
0 kommentar(er)
