RobotPy: Python for FRC

[Peter Johnson]

I've implemented dynamic loading of C modules. The next release of RobotPy will break out many of the C modules into separate loadable object files, the same way that normal Python does. These separate .out files are located in /lib/python3.1/dyn-load on the robot, so they won't clutter up the /ni-rt/system directory.

This should also make distributing other modules (e.g. NumPy) easier, as they can be distributed as separate .zip packages without having to integrate them into the RobotPy executable.

I'm also going to make the wpilib module dynamically loaded. This will make it easier to test with different/beta/custom versions of WPILib. This reduces the size of the basic Python executable down to ~3.5M; the wpilib module is ~5M!

[EricS-Team180]

After they were blown away with WindRiver/C++ last season, I introduced the controls and software team to Python by taking part in Team 342's summerpygames. They got the hang of it and are asking for more. This is perfect!
We'll give it a try.

Thanks,
Eric

[EricS-Team180]

Originally Posted by AustinSchuh

Hmm. That does complicate things. Something else to add to the list of prereqs for SciPy. It looks like some of what I assumed was in SciPy is also in NumPy (matricies, for example) so NumPy might be enough. At the very least, it'll help quite a bit.

...just a thought. You might be able to f2c the FORTRAN. I've had success with this with older versions of vxWorks.

[Tom Bottiglieri]

A bit off topic, but the book "Learn Python The Hard Way" seems like a great guide to learning how to program, using Python. (Different than learning how to use Python )

This might be good supplement to RobotPy.

http://learnpythonthehardway.org/index

[andreboos]

I built the most recent version from source. The make_dist.bat file copies the loadable modules to "dyn-load", but Python looks for the modules in the "lib-dynload" directory. I fixed the bat file to reflect this, and it works fine now. Before, boot.py couldn't find the time library and aborted.

I post this here because the discussion boards on FIRST Forge are limited to project members (total project members: 1).

[Peter Johnson]

Originally Posted by andreboos

I built the most recent version from source. The make_dist.bat file copies the loadable modules to "dyn-load", but Python looks for the modules in the "lib-dynload" directory. I fixed the bat file to reflect this, and it works fine now. Before, boot.py couldn't find the time library and aborted.

I post this here because the discussion boards on FIRST Forge are limited to project members (total project members: 1).

Sorry about the problem, although you shouldn't have seen it with the latest git sources (it was fixed in http://git.tortall.net/cgit.cgi/Robo...b7ade9051151a). The zip files have also been updated.

You should be able to request project membership on FIRST Forge to post there... let me know if you are unable to for some reason; maybe there's a setting I missed. Thanks!

[andreboos]

Hmm. I checked out from the git repository just this morning. However, all the other files seem to match the most recent changeset, so maybe it's a client-side issue.

Anyways, I'm happy to report that I've finished porting last year's code to Python, and as a separate project, modified our existing C++ code to load Python to run an autonomous script that our drive team can edit while queuing for a match with alliance members, with surprising ease. I copied the RobotPy/Python directory and the wchar.h and wchar.c files into the old directory, expanded the include paths to include the root directory (containing the wchar files), /Python/, and /Python/Include/, and compiled. In our autonomous method I put the contents of RobotTask(), replacing ROBOTPY_BOOT with the path (on the robot) to our Python autonomous script. Then I uploaded the resulting .out file to the robot, leaving the existing Python libraries intact.

NetConsole shows many error messages about duplicate symbols when Autonomous mode starts, probably as a result of linking WPILib to the C++ code and also loading the _wpilib.out from RobotPy. However, WPILib also throws (fatal) "resource resuse [sic]" errors when WPILib instances from the Python code are not properly deleted before the script ends and the same resources are used in teleoperated code. I'm still resolving the kinks in WPILib on Python, but Python itself runs fine.

[Peter Johnson]

Originally Posted by andreboos

However, WPILib also throws (fatal) "resource resuse [sic]" errors when WPILib instances from the Python code are not properly deleted before the script ends and the same resources are used in teleoperated code. I'm still resolving the kinks in WPILib on Python, but Python itself runs fine.

Unfortunately I haven't yet been able to get Python to always call the WPILib destructors. It does seem to call them if you explicitly del the WPILib Python variables, but that's obviously non-ideal. I'm actively trying to get this fixed (it's tied in with how Python unloads modules, so it's somewhat of a pain). Note it'll probably always be necessary to call gc.collect() explicitly to ensure the objects are destroyed (the default boot.py will do this).

Glad you were able to have some early success even not using the library how it's designed (as a full-up Python solution)!

[dbeckwith]

Python sounds great! Is it legal for the 2010 season? And are there handlers or image-recognition algorithims for the camera?

[Peter Johnson]

Originally Posted by dbeckwith

Python sounds great! Is it legal for the 2010 season? And are there handlers or image-recognition algorithims for the camera?

You mean the 2011 season? See the second FAQ (http://firstforge.wpi.edu/sf/wiki/do...botpy/wiki/Faq) for the full answer (and a caveat emptor warning). Basically I can't say as I'm not the GDC and can't predict future rules, but I see no reason why it wouldn't be legal according to the 2010 rules. Python itself is available to all teams and thus should be considered COTS code, and to the robot it looks like a C++ program that reads text files.

With regards to the image recognition suite (WPILib Vision library), there's currently no wrappers but it should a straightforward project for an enterprising person who wants to learn a bit about SWIG (see Packages\wpilib\wpilib.i in the source tree).

[aidyl]

Hi,
We are a rookie team (temp# 2012085) interested in using RobotPy. Any recommendations on how to start preparing (websites, tutorials, etc).
Thank you!!

[z_beeblebrox]

I'm very sorry to bring back an old thread, but I'm wondering if this project has gone anywhere since 2010. If not, would everything in it still work? I've heard some very good things about Python, so am curious about maybe using it next year.

[Peter Johnson]

Originally Posted by z_beeblebrox

I'm very sorry to bring back an old thread, but I'm wondering if this project has gone anywhere since 2010. If not, would everything in it still work? I've heard some very good things about Python, so am curious about maybe using it next year.

Yes, we've continued to update it (generally as part of the beta test so it's fully up to date by the time of kickoff). For example, last year we updated it to support the Kinect. Team 294 has used in in competition in both 2011 and 2012 and plan to continue doing so in future years. I believe there are a handful of other teams out there using it as well.

[virtuald]

As Peter said, RobotPy still works and is being maintained. There's a bunch of resources included with the RobotPy distribution, and my team has released our robot code the last two years, both of which are written in python.