Team 1629 Full Autonomous code.

[Philbot]

Here is a link to our team's latest LabVIEW code.

http://beta.gearsinc.org/beta_2008-10-29/

This code permits our 2007 robot to score on the rack in Autonomous mode.

I’ve included two video links showing the robot’s autonomous mode. Note that it's a “mock” rack that isn’t regulation height, but it serves the purpose.

The manipulator and robot positions were “Taught” to the robot by manually driving it to the optimal release position and then telling the robot to “Learn” that position (by pressing a switch on the control panel). The 4 position-
attributes (Tower and Arm position, plus target X and Y) are stored in a file on the cRIO for later recall during Auto Mode.

Video 1 shows the first time the auto code sequence was run. Pretty funny.

http://www.youtube.com/watch?v=WQJO0AtrIbU

Video 2 is about an hour later when the camera tracking has been adjusted and the drive speeds tweaked. The response to the light is still pretty choppy, but considering how little time went into experimenting with the light, it’s not bad.

As you veiw the code... remember that red/blue VI's are all custom.
All the others are "standard".

http://www.youtube.com/watch?v=3o6yoF5WP-g

[willson.thomas]

Sweet.

Thanks for all your excellent work. You have been by far the most active team on these forums and the first to release autonomous code. Thanks for all your hard work.

[willson.thomas]

How quick is the loop in teleop and in autonomous?

[jross]

How quick is the loop in teleop and in autonomous?

The cRIO receives data from the driver station at 50hz (20% faster then IFI). It looks like 1629 put all their code in the driver station loop, so it will run whenever there is new data (like the slow loop on the IFI system).

If you look at the code we posted: http://forums.usfirst.org/showthread.php?t=10215 you'll notice we have a third loop that runs at 100hz.

[Philbot]

How quick is the loop in teleop and in autonomous?

That's a hard question to answer at this point.

I have some basic timing in (and I'll be truthfull, I've only even watched it during Teleoperated), but I don't think we've gotten all the potential delays out of the system yet.

The vision processing loop seems to have very little impact on the overall loop times, and yes, I'm running the closed loop driving code at the nominal driver station packet rate (50hz).

However, there are some differences here between the new and old systems.

The Gyro is integrated automatically by the FPGA code, so you don't need high speed code to keep that working. In the sample code that I "borrowed" the vision processing code from, there is a 100ms wait that will throttle it's execution. So there is no point updating the drive output faster than that.

So far I've been taking the unsophisticated approach and seeing what I get.

I started seeing loop slowdowns in Teleoperated when I really started controlling several systems. However (and this is just my own opinion), I don't think it's processor power related, I think there is some resource which is under contention and causing timing hickups. Once the NI/FIRST guys that we are working with really figure this out I suspect that everything will run just fine at the full 50Hz.

The thing that I always have to remind the control purists is that this is a "slow" mechanical system. Response times are really in the 100's of ms. So if the control system can run at even 20hz, it will still be asking the robot to do things it's not really capable of acheiving. As long as a few time critical calculations are done when need be, the robot will do fine.

Once I get some numbers that I think are "real" I'll make sure I report back to the forum.

[terryh]

Greetings to Team 1629. I have some questions for you all regarding LabVIEW. As is probably the case across the US with many FIRST teams, our team is having a lively debate regarding C++ vs. LabVIEW programming. I'm wondering if you could share some general information about your experiences with LabVIEW. You have generated a lot of code and seem to have a pretty good handle on using the software. Can you answer these questions?

1. How much LabVIEW experience did your programmers start with?
2. How much time have you spent in learning the program?
3. What do you consider the best sources of training for a team with NO Labview experience that will get them up and running in a short period of time? Books? Nat. Instruments tutorials? Web training?
4. Any other information that you think would be valuable for us to add to our debate and to give LabVIEW a fair shake.

Thanks very much for any info you can share. I suspect many teams will benefit from your answer.

Terry
Mentor--TEAM847 PHRED

[Philbot]

1. How much LabVIEW experience did your programmers start with?

Very little. A few of us went to an intro class given by NI, but if you read my signature, you'll see what I think is the most valuable thing for teams to do.

2. How much time have you spent in learning the program?

Once the beta software came out, I'd say it took a couple of weeks to get comfortable with LabVIEW basics, as well as getting the robot to work. Thinking back to my first FRC experience (2006) I'd say it took about the same amount of time to get comfortable with the C template from IFI, and I already knew C like the back of my hand.

3. What do you consider the best sources of training for a team with NO Labview experience that will get them up and running in a short period of
time? Books? Nat. Instruments tutorials? Web training?

Read my signature....
Beyond that, drilling down into the VI's that will come with the controller are a great learning method.... just like with the old IFI, and Kevin Watson code.

4. Any other information that you think would be valuable for us to add to our debate and to give LabVIEW a fair shake.

Just try it.

And don't automatically assume that the transition from C to C++ will be a snap. This is not a case of starting to add C++ elements into an existing C program. You will need to jump head-first into a fully Object Oriented C++ program implementation. There will be some conceptual learning issues there as well

Keep an eye out for a bunch of new NI-FRC training videos.

[terryh]

Phil,

Thanks very much for the reply. This gives me a great baseline for continuing the discussion with the team.

Any other teams want to weigh-in with their experiences? This is helpful for those of us who are waiting for our controllers and the libraries.

[Charles Harris]

Although not from a beta test team, I have been working with two FTC teams using LabView this season. I have about 20 years experience using C/C++ and have used LabView in several work related projects prior to the start of this year's FTC season. I have been helping FRC teams with software for the past 7 years. I am preparing to do two FRC preseason software workshops in Richmond, VA and Washington, DC. After observing and helping my FTC students use LabView and reading the available documentation for the new control system I am planning to make the following recommendations at the workshops:

If “you” do not know C/C++ already, do not start learning it now for use in January 2009, use LabView.

If “you” have been frustrated using C in the past and have had difficulty communicating with sensors and/or developing a functional autonomous mode, try using LabView.

If “you” have a strong programming team already experienced in C/C++ and have been able to meet your goals and objectives in programming the robot in previous seasons, continue to use C/C++ (but keep an open mind about LabView).

My new students (did not program the robot last year) have had an easier time using LabView than my experienced programmer.

From my personal perspective: when I had my "programmer's" hat on LabView was frustrating at times; however, once I put on my "electrical engineer's" hat I was very much at home.

[jross]

If “you” have been frustrated using C in the past and have had difficulty communicating with sensors and/or developing a functional autonomous mode, try using LabView.

Both LabVIEW and C++ support the same sensors out of the box, using the WPI Robotics Library. Both support many more types of sensors then the IFI controller did, out of the box.