RobotPy 2010.beta2
 

I've just released a new version of RobotPy (Python for FRC), 2010.beta2. The RobotPy site has moved to FIRST Forge at the encouragement of Brad Miller at WPI; please update your bookmarks. The new location is:

http://firstforge.wpi.edu/sf/projects/robotpy

Major changes from 2010.beta1 release:

• Separate packages for the Python core (interpreter and libraries) and the WPILib module. The Python core itself no longer depends on WPILib. This decoupling will allow for separate releases of WPILib for different years (e.g. for beta testing or maintaining old robot code).
• Dynamic loading support for binary modules; many of the standard Python modules are now dynamically loaded (as is WPILib). This will make it easier to distribute additional modules as separate packages in the future as well (e.g. NumPy).
• RobotBase, SimpleRobot, and IterativeRobot classes are now provided.
• You can now derive Python classes from PIDSource, PIDOutput, SpeedController, and Joystick and pass the derived classes to WPILib (e.g. PIDController). This enables custom PID control in Python.

The wiki pages at FIRST Forge contain the most recent documentation. In the coming weeks I plan to work on improving the documentation further; currently it mostly describes the differences between the C++ WPILib and the Python version.

I expect to complete translation of 294's 2010 robot program to Python on Wednesday. When I post it for download I will also make an announcement here.

Re: RobotPy 2010.beta2
 

I have a complete robot program already coded up, all it needs are comments

Re: RobotPy 2010.beta2
 

Good job robototes!

Re: RobotPy 2010.beta2
 

want a copy?

Re: RobotPy 2010.beta2
 

If you don't mind :).

Re: RobotPy 2010.beta2
 

well crap.


I accidentally deleted it all, so it looks like i have to remake it :(

Re: RobotPy 2010.beta2
 

back this one up

Re: RobotPy 2010.beta2
 

i even made a computer testing interface for this one:

http://www.chiefdelphi.com/forums/sh...ad.php?t=87630

too lazy to copy the bbcode

Re: RobotPy 2010.beta2
 

i tried installing robotpy today, and it didn't work

Re: RobotPy 2010.beta2
 

Could you elaborate? Did you get any error messages in NetConsole? In order to help you get it working, I need more detail than simply "it didn't work".

Re: RobotPy 2010.beta2
 

we didn't have netconsole, all we got was watchdog/no code

Re: RobotPy 2010.beta2
 

You should definitely enable NetConsole to see what's going on. If it's simply "no code" that means the Python interpreter isn't starting. Watchdog likely means your Python code is raising an exception. NetConsole will show the details of any exceptions being raised.

Re: RobotPy 2010.beta2
 

How do I do that?

Re: RobotPy 2010.beta2
 

See http://first.wpi.edu/FRC/frccupdates.html. There is a client download link and instructions for setup of netconsole under the C/C++ Team Update 4.0 section.

Future versions of the Imaging Tool will make it easier to enable the netconsole server portion. It's installed on the cRIO already, just not enabled by default in the C++ version.

Re: RobotPy 2010.beta2
 

oh, what port is this on?

Re: RobotPy 2010.beta2
 

It's UDP broadcasted by the robot to 10.255.255.255, port 6666. There's no data format, the UDP payload is simply the console output.

Re: RobotPy 2010.beta2
 

so i listen for a broadcast on port 6666?

how would i do this with netcat?

Re: RobotPy 2010.beta2
 

Untested, but something like "nc -u -l -p 6666" ?

Remember that to get anything you need to have the NetConsole server running on the cRIO (by editing ni-rt.ini per the instructions in the above link).

Also I've only seen this work over wired connections (on the PC side); wireless to the robot works fine, but the PC has to be hardwired to the router (I think this has to do with it being broadcast instead of unicast).

Re: RobotPy 2010.beta2
 

UDP 6666 for packets to the client.
UDP 6668 for packets to the cRIO.

Re: RobotPy 2010.beta2
 

You can use this utility (since netcat doesn't play very nicely with listening for broadcast UDP).

You can then use the script here.... or just run (after compiling ncb.c):
Enjoy,
-Joe

Re: RobotPy 2010.beta2
 

thanks :)

so i add netconsole.out to the startupdll's?

Re: RobotPy 2010.beta2
 

Add it to the beginning of EarlyStartupLibraries. Guess you didn't find the instructions.

Re: RobotPy 2010.beta2
 

just confirming

Re: RobotPy 2010.beta2
 

This is great!

I played with RobotPy a little, and here's a problem I encountered. When our code exits due to some error, it waits 5 seconds and then starts our script again, which is how we load new code.

However, when it's an actual error, not an intentional interrupt for new code, while we look at the source and fix the problem it keeps on restarting every 5 seconds. Eventually it crashes with some memory error and we have to restart the robot. (I don't have the output in front of me; I'll try and reproduce it so I can post the exact error.)

Has anyone else had this issue? How can I prevent it from doing this?

Re: RobotPy 2010.beta2
 

I will fix this in the first 2011 release (Wednesday at the latest). What I will do is handle the restart/reload exception specially; any other exception will result in ending the user program (requiring a full robot reboot).

Re: RobotPy 2010.beta2
 

Full robot reboot as in a power cycle? That seems like it could be improved (though, timely release of the first 2011 release is probably more important). The advantage of quickly reloading code without a power cycle is great, and syntax errors are probably common.

How long does a power cycle take for most people? With our LabView code (I don't know if your language makes a difference), it took a minute or two before we got communications after turning the robot on.

If the error is happening because the user code is being loaded/unloaded so often, then I can't think of any good fix that doesn't involve fixing the memory error/bug.

Re: RobotPy 2010.beta2
 

When there's an error can't it just sit there and wait for you to load new code? Maybe that's something that could be done in robot.py inside of run(), if it catches an exception then checkRestart() continuously.

Re: RobotPy 2010.beta2
 

By scanning the /py/ directory for updated date/time/size files (maybe non-ideal because of multiple files...)? Or wait for a joystick button press?

Re: RobotPy 2010.beta2
 

Unfortunately the memory leak appears to be very difficult to fix (it's a leak in Python itself).

With regards to reboot time, you don't need to power cycle the whole robot. Clicking the "Reboot Robot..." button on the Driver Station Diagnostics tab only takes 20-30 seconds. Still non-ideal, of course, but much faster than a power cycle (the additional delay is due to the wireless network startup time).

Re: RobotPy 2010.beta2
 

Wait for a button press, same as usual. I was just going to try wrapping the whole run method in a try..except, and in the `except' continuously check for a joystick button to raise the restart runtime error.

http://pastebin.com/9bcUEy96

Re: RobotPy 2010.beta2
 

Wait for a joystick button press. Like this maybe:

http://pastebin.com/9bcUEy96

Re: RobotPy 2010.beta2
 

With a joystick, same as usual:

http://pastebin.com/9bcUEy96

Re: RobotPy 2010.beta2
 

Waiting for new code would be good. However, if possible, it shouldn't be done in robot.py. I like the fact that run() exists because it lets you see what the code is doing (unlike in C++, where they use a magic macro), but checking for new code seems like it should really be somewhere other than user code (robot.py). It's probably possible to do it outside of user code though.

Joystick button press might work, but how will you know which joystick and button to use? I suppose you could just use joystick 1 button 1. It's unlikely that a team doesn't have a joystick plugged in...

Is that this issue (that is fixed in Python 3.1.3)? Is it too difficult to move RobotPy to 3.1.3?

Re: RobotPy 2010.beta2
 

Currently, normal code reloads in RobotPy are handled in robot.py user code by calling the checkRestart() function, which checks joystick 1 button 10 but can be changed. It seems like waiting after a crash could be implemented similarly, without a major change to the underlying framework (not sure how hard that would be). This also makes it easy to remove for competition...wouldn't want to restart the program in the middle of a match!

Re: RobotPy 2010.beta2
 

Does wpilib still work if the code is not in StartCompetition()?

If so, that could work! Something like this (if done away from user code in boot.py) http://pastebin.com/iqZjYni0

Though, that requires that the user have a CheckRestart function.

EDIT: Also need a wait in that snippet in the loop so that it doesn't take up all the cpu.

Re: RobotPy 2010.beta2
 

What about instead of a joystick press, just listen on a socket for some string? It's easy enough to write a script to connect to that socket and send it.

Re: RobotPy 2010.beta2
 

That's exactly what I was just thinking this morning as well. A little program runs on your PC with a button for "Code Reload".

Note that the latest code (I don't recall if 2010.beta2 did this, but it's in the current repo) implements the 5 second restart loop entirely in Python (in boot.py). If boot.py exits the C++ level terminates as well. So it's easy enough to customize the restart behavior however you like.

Re: RobotPy 2010.beta2
 

Can I recommend that you do something that Java does... leverage the NetConsole input stream to signal the cRIO. You can just use a scanf from stdio... then a person using NetConsole or the serial console or wherever can easily reload. You can still make a utility that sends that keystroke to UDP port 6668 and give it a button to click if that's the ultimate interface you want.

-Joe