-
Notifications
You must be signed in to change notification settings - Fork 0
Python Wrapping
While most of our systems are written in C++, the behavior system is written in Python. Since behaviors can't run all by themselves and need information from or need to control the C++ systems, the two languages have to interact.
Standard Python is implemented in C, and Python is billed as easily extensible with C or C++. The Python/C API is the most immediately obvious way to extend Python (provide new, specific functionality to Python) or embed it in a C or C++ program (use Python for a small part of a larger program, which is essentially what we do). If you #include "Python.h" you can use the various definitions in the API in your C/C++ program and thus gain access to Python from C++. However.
For the type of embedding that we do in particular, using the Python/C API is a huge headache. This simple example is not really all that simple, and our C++ systems are far from simple.
To save ourselves many a headache, most of our C++ systems are "wrapped" (meaning that their information is provided for Python's use) using Boost.Python. There are many Boost C++ libraries and we use several in our code base, such as the smart pointer library, along with Boost.Python. (If you're not familiar with the idea of a library, hit up the wikipedia article. `#include <boost/python.hpp> to use the main Boost.Python library; note that this automatically includes Python.h too, and you can use the Python/C API with Boost if necessary.
Looking at this example, you can see that this library makes it a lot easier to wrap a C++ function than the Python/C API, although still not always a complete piece of cake. Most of the information needed to work with Boost.Python can be found in its reference pages, but this library is somewhat under-documented, and the doc pages can be frustrating. The tutorial, however, is fairly helpful, as are a few other pages (here for example).
Each of the wrapped systems should have its own "Py[system name].h/cpp" files, but this rule varies a little. They are, in no particular order:
- LEDs - PyLights.h and PyLights.cpp
- RoboGuardian - PyRoboGuardian.h and PyRoboGuardian.cpp
- Sensors - PySensors.h and PySensors.cpp
- Speech - PySpeech.h and PySpeech.cpp
- Logging - PyLoggingBoard.h and PyLoggingBoard.cpp
- Motion - PyMotion.h and PyMotion.cpp
- Constants - PyConstants.h and PyConstants.h
- Combination Objects - PyObjects.h and PyObjects.cpp
- Localization - PyLoc.h and PyLoc.cpp
- Vision - PyVision.h and PyVision.cpp
- Comm - wrapped within Comm.cpp for now