RobotPy 2012.1

[Peter Johnson]

I've released the first release of RobotPy for the 2012 season: 2012.1

Download from http://firstforge.wpi.edu/sf/go/proj...robotpy.2012_1

Major changes from 2011.3 release:

• Python upgraded to 3.2.2!
• WPILib rev 2993 (2012/01/08 release) support (all classes including Kinect). Requires cRIO image v43.
• Support for both 8-slot and 4-slot cRIOs.
• New loader / boot.py which tries to improve the behavior of instant reloads. If the user code raises a SystemRestart exception, the entire Python interpreter exits and should be restarted by the loader. This is still not all that reliable as the interpreter doesn't do a particularly good job of cleaning up after itself, so use with caution at the moment.
• Unified release (one download) with simple installer.

Release notes:

• A number of the new additions to WPILib (Buttons, Commands, NetworkTables, Preferences, SmartDashboard) are implemented via native Python instead of wrapped C++. They have seen only moderate testing but as they're native Python they should be easy for anyone to fix if they're broken!
• While the new version is 99% compatible with existing code, if you wrote an __init__() function in your SimpleRobot/IterativeRobot-derived main robot class, you need to ensure you're calling super().__init__(), otherwise you'll see an exception raised from the library level about not being able to find "self.ds.InDisabled".
• Vision support still isn't all that great. All of the high-level WPILib "vision" classes are wrapped but most of the lower-level "nivision" functions have not been. Depending on your coding level, if you want to use the nivision functions, you're probably better off writing some high-level vision processing function in C++ and wrapping it to call from Python. This is relatively easy to do (see the robotpy source code's Packages subdirectories).

GitHub (for those interested in the details): http://github.com/robotpy/robotpy

[shuhao]

Looks quite awesome.. I would consider python as my primary language... but given the fact that the teams is not gonna be too happy with me if i use not officially supported software.. I probably won't use after the competition is over...

Hopefully FIRST could adopt this as well!

[jhersh]

How are you deciding what to wrap and what to reimplement?

[Peter Johnson]

Originally Posted by jhersh

How are you deciding what to wrap and what to reimplement?

Basically I decided to wrap the low level "core" classes, and reimplement the higher level frameworks (NetworkTables, SmartDashboard, Commands). My main reasoning was that the higher level frameworks would feel much more Pythonic (e.g. natural to use) if duck typing could be used for the various interfaces (e.g. SmartDashboardData, NetworkTableChangeListener) rather than forcing people to derive from multiple base classes and remember to call all of the base class __init__ methods (required when you have a wrappered class or bad things can happen). Also, when the user code fails, error messages tend to be a lot better for native than for wrappered classes.

Something like PIDController is on the line; currently it's wrapped C++ but I'm definitely leaning towards making it native Python in the future.

I perhaps could have saved myself some work by wrapping a modified NetworkTables rather than reimplementing the whole thing, but I'm pretty pleased with the end result. Line counts of the reimplementations (SLOC):

NetworkTables.py: 1201
Preferences.py: 384
SmartDashboard.py: 355
Commands.py: 884
Buttons.py: 116

[jhersh]

If you implemented the Network Tables completely in Python, does that mean that it is a portable implementation that runs on a PC also?

Did you model your ports on the C++ implementations or the Java implementations or both? There have been several bug fixes between the last beta release and the kick-off release in the command stuff. Are you tracking bug fixes in your python implementations?

[Peter Johnson]

Originally Posted by jhersh

If you implemented the Network Tables completely in Python, does that mean that it is a portable implementation that runs on a PC also?

Did you model your ports on the C++ implementations or the Java implementations or both? There have been several bug fixes between the last beta release and the kick-off release in the command stuff. Are you tracking bug fixes in your python implementations?

Yes, it runs on a PC also.

C++ implementations (basically I copied and pasted the C++ code and did line-for-line translation). Considering I reported most/all of those bugs (discovered while reimplementing), I believe so. I do check for deltas in the C++ source between each WPILib revision as I often need to update my wrappers.

[BotnEyedJoe]

About the vision stuff: I am not quite understanding how to use it.

Last year, this worked:

import wpilib
import vision
import nivision
self.axisCamera = vision.AxisCamera.GetInstance()
...

Side note: It looks like this year's approach makes the import nivision extraneous.

But the problem I have is on the "import vision", where I get a bunch of undefined reference messages:

Importing user code.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqGetMeterArc.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqInverseFFT.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqFindLCDSegments.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqReplaceComplexPlane.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqFFT.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqConjugate.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqTruncate.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqCreateCharSet.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqExtractComplexPlane.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqFlipFrequencies.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqCreateClassifier.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqReadMeter.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqAttenuate.
Warning: module 0x17a1198 (_nivision.pyd) holds reference to undefined symbol imaqReadLCD.
(unloading partially loaded module _nivision.pyd)

Anyone have ideas on what I am doing wrong? I have the v43 cRIO image, and the RobotPy 2012.1 distribution.

[BotnEyedJoe]

Oh, hah! The one piece of information I left out, that this is on an 8-slot cRIO, turns out to be the key. And this issue turns out to be caused not at all by RobotPy, but by the cRIO image v43, for cRIOFRC (the 8-slot version).

There are two versions of nivision.out delivered as part the v43 cRIO image, one for the 4-slot and another for the 8-slot cRIO. It turns out that they do not both have the same symbol table.

All of the "undefined" symbols I quoted in the prior message are defined in the cRIOFRC2 (4-slot) version of nivision.out, but *not* in the cRIOFRC (8-slot) version.

So I worked around this by commenting out these symbols from the Packages/nivision/sip/nivisionmod.sip file and rebuilding RobotPy. And so the code fragment I showed before now works fine.

[virtuald]

RobotPy 2012.2 is out, has the latest changes to WPILib and fixes the undefined references problem with the vision packages.

http://www.chiefdelphi.com/forums/sh...d.php?t=102361