While the regular API can be accessed from within the simulator (e.g. from an embedded script, an addon, a plugin or the main client application), the remote API, the ROS interfaces and the BlueZero interface can be accessed from almost any possible external application or hardware (including real robots, remotecomputers, etc.). The auxiliary API is not an interface per se, but more a collection of helper functions that can be embedded, and that operate on their own. The other interfaces item groups all possibilities for the user to extend the available interfaces. Above figure illustrates an overview of the various interfaces.
an embedded script
The ROS node
The BlueZero node
remote API client
1.an embedded script：能够自定义仿真，例如一个场景或者模型
An embedded script is a script that is embedded in a scene (or model), i.e. a script that is part of the scene and that will be saved and loaded together with the rest of the scene (or model).
1.1Simulation scripts: simulation scripts are scripts that are executed only during simulation, and that are used to customize a simulation or a simulation model. The main simulation loop is handled via the main script, and models/robots are controlled via child scripts.
- Associated scripts form the basis of V-REP’s distributed control architecture.
1.1.1The main script
A main script is a simulation script. By default, each scene in V-REP will have one main script. It contains the basic code that allows a simulation to run. Without main script, a running simulation won’t do anything. 每一个simulation都需要一个main script.
- the initialization function: sysCall_init
- the actuation function: sysCall_actuation
- the sensing function: sysCall_sensing
- the restoration function: sysCall_cleanup
1.1.2 Child scripts
child script 是一种仿真脚本。可以控制模型或者机器人。每一个scene都支持无数的子脚本。child scripts和scene objects是绑定在一起的。.You can attach a new child script to an object by selecting the object, then navigating to [menu bar –> Add –> Associated child script].
有non-threaded child script 和threaded child script 两种：
non-thread script是白色的，不像Customization scripts是全黑的。thread child scripts是绿色的。
18.104.22.168 non-thread script
Non-threaded child scripts contain a collection of blocking functions. This means that every time they are called, they should perform some task and then return control. If control is not returned, then the whole simulation halts. Non-threaded child script functions are called by the main script twice per simulation step from the main script’s actuation and sensing functions. The system will also call child scripts when appropriate (e.g. during child script initialization, clean-up, or when a joint callback function or contact callback function is defined). This type of child script should always be chosen over threaded child scriptswhenever possible.（尽可能使用non-thread script）
22.214.171.124 thread script
Threaded child scripts are scripts tha**t will launch in a thread**. The launch of threaded child scripts is handled by the default main script code, via the sim.launchThreadedChildScripts function, in a cascaded way. When a threaded child script’s execution is still underway, it will not be launched a second time. When a threaded child script ended, it can be relaunched only if the execute once item in the script properties is unchecked. A threaded child script icon in the scene hierarchy is displayed in light blue instead of white to indicate that it will be launched in a thread.
Threaded child scripts have several weaknesses compared to non-threaded child scripts if not programmed appropriately: they are more resource-intensive, they can waste some processing time, and they can be a little bit less responsive to a simulation stop command.
1.2 Customization scripts: are embedded scripts that can be used to customize a simulation scene to a great extent. They are attached to (or associated with) scene objects.
– This is a customization script. It is intended to be used to customize a scene in
– various ways, mainly when simulation is not running. When simulation is running,
– do not use customization scripts, but rather child scripts if possible.
- they run non-threaded.
- they are attached to (or associated with) scene objects (i.e. they are associated scripts). Associated scripts form the basis of V-REP’s distributed control architecture, and share the convenient property to be automatically duplicated if their associated object is duplicated.
An add-on in V-REP is quite similar to a plugin: it is automatically loaded at program start-up, and allows V-REP’s functionality to be extended by user-written functionality or functions. Add-on scripts are written in Lua. Two types of add-ons are supported:
- Add-on functions: add-on functions appear first in the add-on menu. They can be seen as
functions that will be executed once, when selected by the user. Importers and exporters can
conveniently be implemented with them.
- Add-on scripts: add-on scripts are executed constantly while the simulator is running, effectively running in the background. They should only execute minimalistic code everytime they are called, since the whole application would otherwise slow down. Add-on scripts are called differently depending on the simulation state:
我们不能用python 或者c++来写脚本。但是我们可以使用 regular API来写插件。
Or you can write an external Python program, and use the remote API to interface with V-REP.
If you want to write a script, use Lua. It has a very simple syntax, easy to understand, and you can get the most of the job done by studying the code in the examples.
Access from unassociated code
Unassociated code is code that is not attached to any scene object. This includes all the code written for plugins, add-ons,
remote API clients, external ROS nodes, external BlueZero nodes, and the main script.
Access from associated code
Associated code is code that is associated with a scene object (i.e. attached to a scene object). This includes all the code written for child scripts or customization scripts.