Python interface for comm module

[napratin]

Serial communication code in comm is currently written in C/C++, other modules (esp. sensors, action, navigation) need a Python interface.

Basic requirements of such an interface:

• expose movement, arm rotate and gripper commands (must return after action is completed and acknowledged with feedback)
• expose sensor reading commands (data returned per sensor/sensor type)
• (optional) asynchronous callback registration/notification for things like fall-off sensors

Options we have:

• write the Python interface as an extension module
• use ctypes
• use Boost.Python (possible overkill; installation might be too tedious)

Not having dealt with writing python interfaces or C/C++ shared libraries much, I don't know how much effort either will take. They all seem to require that the C/C++ code be compiled to a shared library (.so, I guess).

I also recommend looking into porting the code to Python as an alternative, esp. since serial communication in Python is a breeze.

[napratin]

I can build a stub Python comm module, with some basic communication (or fake the communication part), mainly to specify the interface that I am expecting. Someone with better experience and/or investment in this, please pick up and implement the Python wrapper/port the code.

[dfarrell07]

Will you own this issue @bpulluri? If so, go ahead and assign yourself.

[bpulluri]

Yeah.. will resolve it by tonight On Mar 2, 2013 10:43 PM, "Daniel Farrell" notifications@github.com wrote:

Will you own this issue @bpulluri https://github.com/bpulluri? If so, go ahead and assign yourself.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/9#issuecomment-14340991 .

[napratin]

Some progress on serial communication from my end...I first checked in a skeleton module with stubs for methods that I thought we would need. While enhancing that, I started thinking about how different processes would share the serial line, and ended up implementing some of the functionality (see qwe/comm/serial_interface.py):

• SerialInterface contains a queue where commands are submitted using putCommand(). It generates and returns a unique (random) command ID used to later retrieve the corresponding response.
• A separate dedicated thread monitors and services the queue, i.e. sends commands over serial, retrieves responses and stores them in the responses dict with command ID as key. This ensures only one thread ever accesses the actual serial port.
• Results are retrieved using a separate call, to getResponse(), passing in the command ID. It can optionally block till the command has been serviced (this is usually true, and hence the default).

For now, when serial_interface.py is run standalone, it connects to the specified serial port (command-line arg; see main method), starts an interactive loop sending one command and retrieving a response each iteration. I've left other method stubs in SerialInterface for specific high-level commands that we'll need. Python's threading API is supposed to be compatible with multiprocessing, so it should be possible to change this from a "multi-threaded" solution to a "multi-processing" one.

Ideally, controller should instantiate a SerialInterface object and pass it to other components that need to send commands (navigation, action, etc.). But if object sharing is difficult, the main command queue encapsulated in SerialInterface can be shared so that other processes can write to it directly (unique command ID generation will need to be handled accordingly), while a single SerialInterface object running on a dedicated process would issue commands and retrieves responses (similarly, the responses dict would also need to be shared). @dfarrell07: It's up to you how you want to do this. Let me know if I can help.

Note: Commands and responses are currently assumed to be plain text strings, '\n'-terminated. I feel this is intuitive, but it might be a problem if we are exchanging binary data.

• One approach could be to have predefined command structures like in the C/C++ serial communication code, and send them as raw bytes. I'd suggest implementing binary versions of existing methods e.g. putCommandB() and execCommandB() to handle this (the main service loop would then call the appropriate method depending on command type).
• An alternate approach is to stick to plain text '\n'-terminated commands. This might imply some extra string <-> number conversions on both ends, but avoids running into data-type mismatch problems (between Pandaboard and XMEGA) and makes debugging easier. I don't know how much of a performance issue it'll be either. @bpulluri: Since you have the best experience regarding this, please decide and implement the stub methods accordingly.

[napratin]

@bpulluri: I noticed you've checked in a binary .so file - has this been cross-compiled for OMAP4 platform? If not, I believe you need to compile it on the Pandaboard for it to work properly. In any case, you should check in a Makefile with the appropriate commands to generate the .so file, and any wrappers if applicable (we should be able to go to qwe/comm and run make). Also, I did not see a corresponding .py file that I was expecting - it would be great if you could comment on how the shared library is to be used. BTW, what method did you end up using? (extension module?)

[napratin]

@bpulluri I believe swig_wrapping.txt contains the commands to compile the shared library. Is that correct? If so, I couldn't find pyComm_wrap.cxx mentioned in it (is it auto-generated by SWIG?). Also, where is the API document located that you mentioned?

[bpulluri]

arpan,

I believe its best to use raw bytes than command strings and we didn't have any datatype mismatch problems the last time we tried.

Yeah, the .so isn't cross compiled and we have to do it on pandaboard . pyComm_wrap.cxx is auto generated on executing commands in swig_wrapping.txt. I wrote in the API file how I used the shared library(not sure if that's the extension module method). The API file is

https://docs.google.com/document/d/1-3K-t7f_aq5d2Ozbjz1TXLjWCLlwCsFz0Kk38AxaBeQ/edit?usp=sharing

On Fri, Mar 8, 2013 at 11:34 AM, Arpan Chakraborty <notifications@github.com

wrote:

@bpulluri https://github.com/bpulluri I believe swig_wrapping.txt contains the commands to compile the shared library. Is that correct? If so, I couldn't find pyComm_wrap.cxx mentioned in it (is it auto-generated by SWIG?). Also, where is the API document located that you mentioned?

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/9#issuecomment-14629198 .

Bhanu Teja pbteja87@gmail.com

[napratin]

@bpulluri: Great work - thanks for pointing me to the API, I should've checked Google Drive myself.

I've cleaned out the shared binary .so file and put in a Makefile (see GitHub comments) so that we can simply run "make" to generate SWIG wrappers and the library. I've also experimented with the module and it seems to work (it's pretty exciting, actually, to see Python talking to serial through C/C++!).

But I faced the same problem you mentioned, regarding array access within structures. It seems to be a non-trivial problem: http://stackoverflow.com/questions/8114030/swig-python-array-inside-structure

The C/C++ code needs further work to include things like different arm IDs, gripper open/close commands, waiting for completion acks, etc. Also, there are still some int variables in the structures which should probably be changed to types with specified bit-depth (int8, int16 etc.?).

If I'm the one completing this, I believe it will be much easier for me to write and debug a text-based interface using native Python serial communication (most of it is already working, see serial_interface.py), using your implementation as a reference, instead of trying to complete the C/C++ code and write the necessary SWIG interface. I also talked to Ethan about this and we think a text-based interface (basically, the one he already has for interactive control) is good to have in place anyways.

I will try to make progress on the binary interface only if we find the text-based one to be too sluggish (which shouldn't be the case as we are not sending commands that frequently). Feel free to enhance the binary interface if you really believe in it!

[bpulluri]

Yeah, it's definitely non-trivial and that's why I was skeptical about continuing with swig. Something to do with python properties. At the least, I felt we need to know how the wrapping works if use of swig isn't straightforward. I do not have much idea about implementation in python but if string based commands is the best possible way, please go ahead with that.

On Fri, Mar 8, 2013 at 11:24 PM, Arpan Chakraborty <notifications@github.com

wrote:

@bpulluri https://github.com/bpulluri: Great work - thanks for pointing me to the API, I should've checked Google Drive myself.

I've cleaned out the shared binary .so file and put in a Makefile (see GitHub comments) so that we can simply run "make" to generate SWIG wrappers and the library. I've also experimented with the module and it seems to work (it's pretty exciting, actually, to see Python talking to serial through C/C++!).

But I faced the same problem you mentioned, regarding array access within structures. It seems to be a non-trivial problem:

http://stackoverflow.com/questions/8114030/swig-python-array-inside-structure

The C/C++ code needs further work to include things like different arm IDs, gripper open/close commands, waiting for completion acks, etc. Also, there are still some int variables in the structures which should probably be changed to types with specified bit-depth (int8, int16 etc.?).

If I'm the one completing this, I believe it will be much easier for me to write and debug a text-based interface using native Python serial communication (most of it is already working, see serial_interface.py), using your implementation as a reference, instead of trying to complete the C/C++ code and write the necessary SWIG interface. I also talked to Ethan about this and we think a text-based interface (basically, the one he already has for interactive control) is good to have in place anyways.

I will try to make progress on the binary interface only if we find the text-based one to be too sluggish (which shouldn't be the case as we are not sending commands that frequently). Feel free to enhance the binary interface if you really believe in it!

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/9#issuecomment-14657790 .

Bhanu Teja pbteja87@gmail.com

[dfarrell07]

It seems like you're well into a native Python comm module, @napratin. Time to close this issue? If you agree, please do so.

[dfarrell07]

I'm going to go ahead and close this, since we're clearly using the Python comm module exclusively.