Go to Post ... you know you are a nerd when you want safety glasses for your birthday! :P - Ashley Christine [more]
Home
Go Back   Chief Delphi > Technical > Programming > Python
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rating: Thread Rating: 3 votes, 5.00 average. Display Modes
  #1   Spotlight this post!  
Unread 01-09-2012, 12:17 AM
Peter Johnson Peter Johnson is offline
With great power comes great I^2*R
FRC #0294 (Beach Cities Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Redondo Beach, CA
Posts: 138
Peter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to behold
RobotPy 2012.1

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
__________________
Creator of RobotPy - Python for FRC

2010 FRC World Champions (294, 67, 177)
2007 FTC World Champions (30, 74, 23)
2001 FRC National Champions (71, 294, 125, 365, 279)

Last edited by Peter Johnson : 01-09-2012 at 12:19 AM. Reason: Mention 4-slot cRIO support.
Reply With Quote
  #2   Spotlight this post!  
Unread 01-09-2012, 07:58 PM
shuhao shuhao is offline
Registered User
FRC #4069 (Lo-Ellen Robotics)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2012
Location: Sudbury
Posts: 138
shuhao is an unknown quantity at this point
Re: RobotPy 2012.1

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!
Reply With Quote
  #3   Spotlight this post!  
Unread 01-10-2012, 01:08 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 892
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: RobotPy 2012.1

How are you deciding what to wrap and what to reimplement?
Reply With Quote
  #4   Spotlight this post!  
Unread 01-11-2012, 01:49 AM
Peter Johnson Peter Johnson is offline
With great power comes great I^2*R
FRC #0294 (Beach Cities Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Redondo Beach, CA
Posts: 138
Peter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to behold
Re: RobotPy 2012.1

Quote:
Originally Posted by jhersh View Post
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
__________________
Creator of RobotPy - Python for FRC

2010 FRC World Champions (294, 67, 177)
2007 FTC World Champions (30, 74, 23)
2001 FRC National Champions (71, 294, 125, 365, 279)
Reply With Quote
  #5   Spotlight this post!  
Unread 01-11-2012, 01:58 AM
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 892
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: RobotPy 2012.1

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?
Reply With Quote
  #6   Spotlight this post!  
Unread 01-11-2012, 02:04 AM
Peter Johnson Peter Johnson is offline
With great power comes great I^2*R
FRC #0294 (Beach Cities Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Redondo Beach, CA
Posts: 138
Peter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to beholdPeter Johnson is a splendid one to behold
Re: RobotPy 2012.1

Quote:
Originally Posted by jhersh View Post
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.
__________________
Creator of RobotPy - Python for FRC

2010 FRC World Champions (294, 67, 177)
2007 FTC World Champions (30, 74, 23)
2001 FRC National Champions (71, 294, 125, 365, 279)
Reply With Quote
  #7   Spotlight this post!  
Unread 01-21-2012, 10:18 AM
BotnEyedJoe BotnEyedJoe is offline
Mentor
AKA: Joe Hurler
no team
 
Join Date: Jan 2007
Rookie Year: 2006
Location: Rosemont, PA
Posts: 29
BotnEyedJoe is an unknown quantity at this point
Re: RobotPy 2012.1

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

Last year, this worked:

Code:
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:

Quote:
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.
Reply With Quote
  #8   Spotlight this post!  
Unread 01-21-2012, 05:42 PM
BotnEyedJoe BotnEyedJoe is offline
Mentor
AKA: Joe Hurler
no team
 
Join Date: Jan 2007
Rookie Year: 2006
Location: Rosemont, PA
Posts: 29
BotnEyedJoe is an unknown quantity at this point
Re: RobotPy 2012.1

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.
Reply With Quote
  #9   Spotlight this post!  
Unread 02-09-2012, 11:37 AM
virtuald virtuald is offline
Registered User
AKA: Dustin Spicuzza
FRC #1418
Team Role: Mentor
 
Join Date: Dec 2008
Rookie Year: 2003
Location: Northern Virginia
Posts: 509
virtuald is a splendid one to beholdvirtuald is a splendid one to beholdvirtuald is a splendid one to beholdvirtuald is a splendid one to beholdvirtuald is a splendid one to beholdvirtuald is a splendid one to behold
Re: RobotPy 2012.1

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
__________________
Co-maintainer of RobotPy - Python for FRC
Creator of pyfrc (Robot Simulator + utilities for Python) and pynetworktables (NetworkTables for Python)

Team #1418: 2014 VA Regional: Finalists, #2 seed overall, Industrial Design Award; DC Regional: Finalists, #6 alliance captain
Team #2423: 2012 & 2013 Boston Regional Innovation in Control Award


FRC Software Resources (including 2014 python code): http://www.virtualroadside.com/FRC/
WPILib Doxygen Repo: http://www.virtualroadside.com/WPILib/index.html
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 10:57 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi