Our team just got done at the Boston Regional this week, and we used python to make our bot go. Our team usually releases its code every year, so I’ll probably post it later on this week.
I thought using python was a really positive thing for our team. Some positives:
Really easy to teach to students, and I felt they picked it up faster than they would have picked up C++ or Java
It was very easy to create a simple test harness to run our code through to help us identify bugs, and it didn’t require a ton of code to do it either
Python is really expressive, and I think it made some aspects of our software design a lot easier
Prototyping something (and testing it) was really fast, and helped us build things that worked a lot faster
Some negatives:
If you fat-finger something, it’s possible that the robot code would throw an exception in the middle of a match (however, this was largely mitigated by having a comprehensive test program that we ran each time before we uploaded code to the robot)
I never got around to removing the pyc file generation for our code, but I felt there were some instances where if I didn’t delete the pyc files, then the robot would just execute the code cached there instead of using code that was just uploaded to the robot
I’m curious to see who else used it for competition this year. What successes/failures did using python bring you?
We were previously a C++ team, and went into this season cautiously looking at Python, figuring the upside potential made it worth some investigation, but that we would do a dual-development side-by-side with C++ in case we hit a show-stopping problem later on.
Well, a couple of weeks or so into build season, Python was such a smooth and complete experience [other than that camera thing which is well covered in a separate thread and was really a WPILib problem anyway], we decided to drop the C++ line and go Python. And we never looked back…
When competition season came, I had nightmares the night before our first regional, thinking that the show-stopper I was worried about was about to happen; something along the lines of: we get the robot onto the field and it can’t communicate with the field or something esoteric that causes us to miss matches. Ha! We got out on the field the first time, and two other robots had that problem, not us; and we never had any problem with the field in two regionals. The Python experience was just 100% reliable out on the field, judging by our experience.
We would echo many of the comments in the OP: students pick it up much more easily, making and fixing code is just so much faster!! Yeah, typos and little defects don’t bite you until you run the code they are in, but we used a bench-top cRIO to smoke-test the code before using the code in the real robot, and that mitigated nearly all those issues. And even when we goofed on the real robot, it was so fast and easy to fix, that people were seldom waiting for the software to get working again.
I could go on and on, but generally we very much recognize that Python was a big positive for us this season, and we are not going back to C++ as long as Python is around.
We actually didn’t use a tool, I just created a file called ‘test.py’, imported robot.py, and ran the program like the cRio would.
We have print statements sprinkled throughout the program, so we just verified the operation of the program manually – and honestly, the biggest thing I was worried about was accidentally throwing an exception because of a syntax error, so the actual results didn’t always matter to us – just the fact that it ran all the way through our autonomous routine and a few rounds of operator control was good enough for me.
Of course, we also had a lot of things like the following sprinkled throughout our main loop too, just in case we missed something…
try:
# call some complicated function in another module
except:
# swallow any exceptions if we're in a real match...
if not wpilib.DriverStation.GetInstance().IsFMSAttached():
raise
We experimented with Python, but went with Java. Python was a proof of concept that I imagine will revisited next year. At least for some initial work even if we don’t use it in competition.
For this year, it turned out that Python didn’t support something we needed. I forgot if it was speed control on Jaguars or something with the camera.
Python worked (and is still working) great for us. Really nice to work with. The whole misspelling thing is kind of annoying, but easy to fix. No problems at all during matches or inspection. Probably the biggest bonus was how fast it was to code, not just at the lab during build, but also on the field. I’m both the programming captain and driver this year, and right before our first match, I realized I had forgotten to put in a “no autonomous” setting. While in queing, I tethered to the programming laptop and set the motors to zero. If I had had to wait for WindRiver to start up, then compile the new code, it wouldn’t have made it to the robot. Later, in LA, all three robots of our alliance had autonomous, but we were the only ones with fork detection. We had never used it on the field before, and on the first match the robot aligned fine, but didn’t quite release the tube. After the match, I quickly increased the telescope drop while scoring, and it worked great after, including a couple 3 tube autos with our alliance.
I did some side testing on the old robot just as a proof of concept. I really loved the quickness of using Python. No waiting for LV to load or Netbeans. It was also easy to program in general. I imagine that we will look at next season as an official language for the team.
(And plus, it is extremely easy to teach! )
On a side note, hopefully we can get some more tutorials up or something to help anyone wanting to switch over to Python.
Yeah, I agree. One thing that would be particularly good to start with is provide python versions of all the default examples provided with Wind River. And while this would be pretty simple to do… haven’t done it yet.
