View Full Version : RobotPy 2010.beta2
Peter Johnson
01-11-2010, 01:46
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.
Robototes2412
01-11-2010, 23:02
I have a complete robot program already coded up, all it needs are comments
Dustin Shadbolt
19-11-2010, 19:00
Good job robototes!
Robototes2412
20-11-2010, 00:00
want a copy?
Dustin Shadbolt
21-11-2010, 23:36
If you don't mind :).
Robototes2412
22-11-2010, 00:08
well crap.
I accidentally deleted it all, so it looks like i have to remake it :(
well crap.
I accidentally deleted it all, so it looks like i have to remake it :(
back this one up
Robototes2412
28-11-2010, 23:20
i even made a computer testing interface for this one:
http://www.chiefdelphi.com/forums/showthread.php?t=87630
too lazy to copy the bbcode
Robototes2412
29-11-2010, 22:20
i tried installing robotpy today, and it didn't work
Peter Johnson
30-11-2010, 00:07
i tried installing robotpy today, and it didn't work
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".
Robototes2412
30-11-2010, 00:43
we didn't have netconsole, all we got was watchdog/no code
Peter Johnson
30-11-2010, 02:41
we didn't have netconsole, all we got was watchdog/no code
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.
Robototes2412
30-11-2010, 21:43
How do I do that?
Peter Johnson
30-11-2010, 22:32
How do I do that?
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.
Robototes2412
30-11-2010, 22:34
oh, what port is this on?
Peter Johnson
30-11-2010, 23:23
oh, what port is this on?
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.
Robototes2412
01-12-2010, 01:28
so i listen for a broadcast on port 6666?
how would i do this with netcat?
Peter Johnson
01-12-2010, 01:51
so i listen for a broadcast on port 6666?
how would i do this with netcat?
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).
oh, what port is this on?
UDP 6666 for packets to the client.
UDP 6668 for packets to the cRIO.
so i listen for a broadcast on port 6666?
how would i do this with netcat?
You can use this (http://git.denx.de/?p=u-boot.git;a=blob_plain;f=tools/ncb.c;hb=HEAD) utility (since netcat doesn't play very nicely with listening for broadcast UDP).
You can then use the script here (http://git.denx.de/?p=u-boot.git;a=blob_plain;f=tools/netconsole;hb=HEAD).... or just run (after compiling ncb.c):
./ncb 6666 &
nc -u 10.xx.yy.2 6668
Enjoy,
-Joe
Robototes2412
02-12-2010, 18:26
thanks :)
so i add netconsole.out to the startupdll's?
so i add netconsole.out to the startupdll's?
Add it to the beginning of EarlyStartupLibraries. Guess you didn't find the instructions.
Robototes2412
03-12-2010, 00:16
just confirming
blakeelias
09-01-2011, 21:49
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?
Peter Johnson
10-01-2011, 00:58
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?
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).
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).
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.
blakeelias
10-01-2011, 02:08
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.
Peter Johnson
10-01-2011, 02:18
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.
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?
Peter Johnson
10-01-2011, 02:20
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.
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).
blakeelias
10-01-2011, 02:48
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?
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
blakeelias
10-01-2011, 02:50
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?
Wait for a joystick button press. Like this maybe:
http://pastebin.com/9bcUEy96
blakeelias
10-01-2011, 02:51
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?
With a joystick, same as usual:
http://pastebin.com/9bcUEy96
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.
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.
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?
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...
Unfortunately the memory leak appears to be very difficult to fix (it's a leak in Python itself).
Is that this issue (that is fixed in Python 3.1.3 (http://svn.python.org/projects/python/tags/r313/Misc/NEWS))? Issue #4838: When a module is deallocated, free the memory backing the optional module state data. Is it too difficult to move RobotPy to 3.1.3?
blakeelias
10-01-2011, 03:40
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...
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!
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!
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.
virtuald
10-01-2011, 09:30
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.
Peter Johnson
10-01-2011, 12:22
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.
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.
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.
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
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.