Robot Programming Mentor and Team Member Discussions

From Jerry September 24, 2011

As Parker wrote, the framework is important. There are exciting new developments since the last build season.
  1. NI now recommends doing vision processing in the driver station laptop instead of in the cRIO.
    • The laptop has a lot more compute power and a GPU. It can run OpenCV. You can fully develop and test your vision program with no robot and no downloads. I'm told there's lots of network bandwidth on the field to get images from the camera to the driver station. The beta test control system s/w includes a small object-oriented Java wrapper around OpenCV to aid development.
    • Let's try it!
  2. Chris Hibner (a control systems engineer and a team mentor) gave an excellent presentation at Championships on how to do some simple simulation to test and tune your robot program.
    • It's a faster, easier, safer way to debug and tune your program.
    • It lets you get functionality nearly ready to go before the robot is available.
    • I uploaded his PowerPoint presentation and example to Google Docs.
    • Chris's example is in LabView. He might have libraries for doing this in Java and C++. That will take tools to operate and view the simulation, one of the strengths of LabView.
    • This technique calls for structuring your robot program in a way that the speed controller objects, sensor objects, and other I/O objects get passed into the constructor rather than instantiated by the robot program's constructor. Then the test harness can pass in objects that simulate the I/O objects. This is called dependency injection. (Here's a Wikipedia article. I didn't read it.)
  3. WPILib now has a framework for FRC programming.
    • It's going out to teams for beta testing. I'm reviewing the doc now and would like to find time to help port it from Java to C++.
    • The SmartDashboard is enhanced. For one thing, you can position various types of gauges and controls.
    • A NetworkTable object synchronizes named values between the robot and the driver stations. Combined with the enhanced SmartDashboard, you can use it to monitor robot data and fault codes, interactively set PID parameters, return vision system results to the robot, mock up driver station controls, and run high level logic on the driver station.
    • (Adding data logging would be an excellent project.)
    • In the new framework, you write a Subsystem class for each robot subsystem (drive train, elevator, wrist, rollers, minibot launcher), with methods for its primitive sensor and actuator operations. You can do this before the robot is ready. You write Commands for higher level operations that run over a period of time like elevator to bottom, pick up a tube, drive with joystick control, and (ultimately) score 2 tubes autonomously. You can set SmartDashboard controls to trigger Commands, and thus interactively test out the program.
    • They rewrote the 2010 Team 190 robot program with this framework. It's much smaller, more understandable, and debuggable. I think they'll include it as a sample program.
I don't know enough to compare this WPILib framework with ROS except that it's demonstrated to fit the job, beta test teams will try it out, and AFAIK it only supports 2 nodes (robot & driver station) with the driver station programs written in Java.

    J

From Jerry September 24, 2011

For training and preparation, I suggest that people get experience before build season with the h/w and s/w components, tool, and development process.
  • Examples: Connect motors & speed controllers, pneumatic cylinders & Spike controllers, sensors. (Also chains, wheels, and everything else.) Do the edit-compile-reload-test loop. (Also the entire CAD development cycle.) Do some debugging. Tune a PID loop. Make the vision system recognize a target. Explore the s/w library. Improve an autonomous mode. Learn robot programming safety techniques.
  • Purposes: Learn by doing. Experience to draw on so we're not figuring everything out under time pressure while building. Understand component capabilities and constraints to inform the design process. Find the docs on everything so you know where to turn. Read some docs.
  • Re-read the robot chapter of last year's game manual. It's been getting less restrictive each year but there's no change summary.
  • It goes easier with a specific project such as making a vision-based autonomous mode before CalGames.
  • Many people should get some experience. At least one person should get experience with each part.
A mature team involves lots of students in non-robot areas: finances, outreach, web site, t-shirt design, strategy, scouting, leadership, recruiting, animation, LED light bulb sales, mascot.
  • Offer ways to get involved in these areas. Don't expect everyone to work on the robot.

    J

From Brian September 23, 2011

I agree that we don't have a lot of things for new members to do right now. However, I believe that there are some of them who have done programming but not robot programming before. They would benefit from doing some programming of botball robots. Also, the botball build system is fairly similar to the FRC one, so that would be good practice.

Also, I think it would be nice if we could get a couple of them involved in porting ROS, but we have to get a starting point first.

From Parker September 23, 2011

Right now, the problem of getting a robot up and running in the sense that we have been doing for the previous years is not big enough to consume the resources of even one person. ( We have consistently done most of the coding after the robot has been built )
Another problem is that the robot code can only really be written when the robot is done. (you need a robot or a partial robot to be able to debug things)
The business logic that gets written to actually drive the robot will get debugged, and thus most likely written when the robot is built.
Thus the only thing we can do before the robot is built is developing frameworks and libraries.
This means that the problems that are left are much harder (We've already done all the easy stuff)
In the past this has meant:
- A re-loader framework that sped up the downloading process.
Currently ideas I've heard of are:
- Porting ROS to the robot.
This means that we have no comprehensive plan or anything yet on what the structure of the code actually running on the robot in competition is going to look like.  Without any such framework, it is going to be really hard to incorporate new team members. Yes, we might be able to run them through some sort of skills workshop or something where we teach them programming concepts, but we won't be able to get them doing anything until they can actually program robot code (which is quite different than tutorial code)
One thing that I would like is to nail down this framework sometime soon.
What would be really cool is to have this framework implemented similarly on a botball robot with enough abstraction where they could write some autonomous navigation code for the botball robot, or some controls thing, or some camera thing, and then be able to stitch that into our FRC robot code. ( meaning we could write navigation code for a robot one year, and use it the next year.) ( I don't know if ROS will do this or not but it sounds like it will work for FRC only if it gets ported )
I think that new members would then be able to fit into this. (we could give them stuff to work on, and then it would work, or they could come up with something and make it work)
Unfortunately, this means my answer is that we are not ready for new programmers yet. ( I propose fixing this is top priority )
I think what you have new members do should be robot related. (it is a robot team after all !)
Thus, what you can do with new members fits into something like this:
  • Have them program in an existing framework (my 2011 code, or WPILib ) ( This is going to be taxing if you want to switch out of the framework )
  • Have them program botball robots. (some of them already have done this. They will most likely learn very little)
  • Have them wait until the new framework is ready.
  • Have them stub out the framework, and then get started on stuff ( people could work on writing camera processing logic (I have stuff that tries to do some of this ) ) ( unfortunately these problems are all much harder than what people expect to be doing (there is only so much direct stick to victor code to write) ) ( they'll learn quickly that they'll have to be reading papers and stuff like that)
I see great potential here in how we can put co-processors on the robot and everything, I think we can and should have several other boards processing extra sensor data (this would be super cool)
I think we can make it work with more programmers, but we need a much better plan. (FRC has much fewer programming limits unlike FLL and to a certain extent Botball which have hardware sensor and processor limits)
I'm willing to help sort these things out, but I don't think I'll be doing much showing up until school is out. ( If you really need me in person, I can arrange for that )
I'm also willing to be available through chat / email to look at robot code and provide suggestions. 
What we do all depends on how many people are interested, and to what level, and with what skills.
( We could have contests and stuff or whatever. I don't know. They will not continue unless we actually have a place for them. )
-Parker

From Wyn September 23, 2011

As you may have noticed in the spreadsheet that I sent out, many people have expressed interest in programming.  I talked to Austin a little and wonder if a two pronged approach to this might be good.  I am sure that there is a wide range of interest and aptitude in this list with many of these people not knowing much of anything about programming and others having a range of experience in the area.  The approach would be to identify a few people who could actually work with Brian on robot code this year and then provide the others the opportunity to learn basic programming so that they might be able to contribute on a higher level in future years.  Some might decide that they like it and go further with it and others decide that they aren't really interested in programming after all.

I think that trying to get everyone up to speed on working on the robot this year is unrealistic but we might be able to use other resources such as Botball robots or some basic projects to teach people programming.

Any ideas?

Wyn