Welcome to the WPILib forum

[BradAMiller]

WPILib was designed a few years ago for teaching robot programming to high schools students here at WPI. Since then it has been enhanced greatly and now there are versions for the 2k4-5 and 2k6 FRC controllers. It is being used by EasyC for FRC as the runtime system inside the robot.

What does it do for you?

• First and foremost - it's easy to use. For example, a program to drive in a straight line using a gyro is literally 11 lines of code - including the braces! And that's the whole program, all you need to write or look at.
• It's free - no licenses, just use it on as many computers as you want as long as it's helping you.
• There is support for all the standard 2006 kit of parts sensors plus a bunch of others that you might want to use, i.e. rangefinders, compasses and encoders.
• It is a true library - that is updates to the library don't require any source code editing or merging with your code. Programs written to the WPILib API from 2 years ago will still work today virtually unchanged.
• It is completely extensible - advanced programmers can add new devices to the library (there is an example of adding a compass in the documentation) and it doesn't require any source code merging to add it to existing programs.
• And, I think the expression is, "we eat our own dog food" - that is to say, we are using the library with Team 190 and any updates are quickly posted back for everyone else to use.
• There is a large document that describes how to use it, and how to extend it (that part intended for the more experienced programmers).

Who should use it?
It you have little C programming experience you could use EasyC - it will help with all the syntax problems and still will be using WPILib since it's built in. But if you are comfortable with C programming and want to use MPLab or Eclipse or other development environment, give WPILib a try. It's easy to get things going fast.

Where to download it
You can download WPILib from my web site. I'll be posting updates there as they come out. There are also lots of example programs.

Support
We'll be monitoring this forum with the help of others at WPI to answer questions as they come up. New versions will be posted on the web site and will be announced on this forum.

Versions
There are versions right now for 2004-5 and 2006 robot controllers. The VEX and Robovation (EDU) versions will go up as soon as I have time. The guys here are bugging me to put up a new version for a battery conditioner/recycler they built out of an old EDU controller.

We hope this helps, and please feel free to email us with comments and suggestions.

[Jon236]

Brad,

Does WPILib have a math function library?

Jon Mittelman
Team236

[Jon236]

In using WPILib with the CMU camera,

1. Should we save Vision Sensor parameters from LabView? And if so, how?
2. Are there any references to the SetServoTracking and SetServoPosition functions?
3. Do the 'pan' and 'tilt' values in the CaptureTrackingData structure refer to values that the servos should have to track the centroid of the desired color?

Jon Mittelman
Team236

[BradAMiller]

Originally Posted by Jon236

In using WPILib with the CMU camera,

1. Should we save Vision Sensor parameters from LabView? And if so, how?

There is no easy way of exporting the camera parameters from LabView. I ran out of time. What you should do is create an instance of a CameraInitializationData struct, fill it in (can be statically initialized) and passed to InitializeCamera(CameraInitializationData *c). You can get the data looking at the labview interface and filling in the struct.

The CameraInitializationData struct is in UserAPI.h. This is a rom struct so you have to initialize it when it is declared.

When InitializeCamera is called, the data will be sent to the camera. When you call StartCamera, it will start tracking with the most recent set InitializationData.

Originally Posted by Jon236

2. Are there any references to the SetServoTracking and SetServoPosition functions?

I'll try to add them to the documentation. But basically they look like this:

void SetServoTracking(unsigned char panTracking, unsigned char tiltTracking)

Where you set panTracking and tiltTracking to 1 or 0 to enable or disable that function. If either are disabled, then there won't be valid pan/tilt data in the returned camera packets.

void SetServoPosition(unsigned char servo, unsigned char position)

The servo is the servo index (value of 0-4) as described in the CMU Camera manual. The position is the PWM value sent to that servo.

Originally Posted by Jon236

3. Do the 'pan' and 'tilt' values in the CaptureTrackingData structure refer to values that the servos should have to track the centroid of the desired color?

The pan and tilt values in the CaptureTrackingData are the values that the camera sends to the servos if it is connected and servo tracking is enabled (see previous question). If servo tracking is disabled the camera sends back 127 all the time.

Hope this helps.

[rodgadashruba]

hey quick question,
My team's programming side is made up of medium level programmers, and some of the great code by Kevin Watson is overwelming. We would be using MpLab regardless. but what are the cons of using WPIlib? it seems like there is none but i may have over looked somthing

[BradAMiller]

Originally Posted by rodgadashruba

hey quick question,
My team's programming side is made up of medium level programmers, and some of the great code by Kevin Watson is overwelming. We would be using MpLab regardless. but what are the cons of using WPIlib? it seems like there is none but i may have over looked somthing

I see two possible reasons that someone might not want to use it.

It is currently a "proprietary" solution. What I mean is that you are free to use it in any way you like, but the source code is not available. This is due to its inclusion in EasyC. This might change in the future.

With that said, I can tell you that we are using the code ourselves and posting new versions whenever it changes. I would consider it pretty unprofessional to be having a version of the library that we were using on Team 190 that wasn't available to everyone.

The other is that it is simply a different style of programming then the default code supplied by IFI. If you are more comfortable with the current code, then by all means, keep using it. We found it much easier to teach students programming using WPILib for 2 week intro to robotics courses.

[Jon236]

Originally Posted by BradAMiller

I see two possible reasons that someone might not want to use it.

It is currently a "proprietary" solution. What I mean is that you are free to use it in any way you like, but the source code is not available. This is due to its inclusion in EasyC. This might change in the future.

With that said, I can tell you that we are using the code ourselves and posting new versions whenever it changes. I would consider it pretty unprofessional to be having a version of the library that we were using on Team 190 that wasn't available to everyone.

The other is that it is simply a different style of programming then the default code supplied by IFI. If you are more comfortable with the current code, then by all means, keep using it. We found it much easier to teach students programming using WPILib for 2 week intro to robotics courses.

Is that curriculum available at a website? I'd love to see it.

Jon

[BradAMiller]

Originally Posted by Jon236

Is that curriculum available at a website? I'd love to see it.
Jon

It isn't there right now - I'll see if I can post it in the future. We use it for our Frontiers program at WPI. It's a 2 week resident program in the summer for robotics.

[rodgadashruba]

well we decided on usign wpilib, and it looks great,

quick question..

how would u program a custom control board that would be conneted to the operater interface?

i hope this is possible
thanks

[BradAMiller]

Originally Posted by rodgadashruba

well we decided on usign wpilib, and it looks great,

quick question..

how would u program a custom control board that would be conneted to the operater interface?

i hope this is possible
thanks

There is no reason to prevent you from doing that and you don't have to use those functions.

We're about to do the same thing. Our team has been writing code to read the ports directly rather than using the functions. Currently they are creating a bunch of "#defines" that give mnemonic names to the ports where the custom controls ane connected. By doing that, they can easily be changed later if the OI is wired differently than originally planned.

It you decide to use the functions, that's ok too. There is no requirement that "trigger1" is actually connected to a joystick. It can be a separate switch.

[Joohoo]

Just curious what interrupts/timers does each encoder and ultrasonic sensor use. Is there a listing of what each sensor uses in terms of internal timers, external interrupts, and how they are configured?

Also has any one used wpilib in addition to the default code?... kevin watson's?

[BradAMiller]

Originally Posted by Jon236

Brad,

Does WPILib have a math function library?

Jon Mittelman
Team236

Jon -

There is no explicit math library. It does link with the standard Microchip libraries so that gets you all the math.h stuff. However I would not recommend doing too much floating point math - it's really slow on the little PIC processor.

Last year we used this library of Cordic math functions - that used 24 bit (short long) arithmetic to do trig functions if that's what you're looking for. It was graciously posted by team 236.

It worked pretty well for us - those holonomic drive calculations needed a bunch of trig functions. So I'd recommend that solution to anyone who needs general purpose trig functions.

With that said, you might also try lookup tables if you don't need a small range of values to be calculated. This only works in some applications and might be useful this year.

[michael714]

Dear Brad,
Can you mix WPILib with default MPLAB code? If so, do you have any suggestions as to how to do so?

My team is using Kevin Watson's camera code as a basis for our coding efforts. However, it would be nice to access the routines in WPILib also (for when we try to do other things like using the Vex ultrasonic range finder).

Do we merely add the following files to our MPLAB workspace: API.h, BuiltIns.h, UserAPI.h and WPILib2k6.lib?

Do we need to add the FRC2k6_library.lib? Or is that the same as the ifi_library.lib file included with Kevin's MPLAB project?

Do we need to add the linker file or can we just use the linker file from Kevin's project?

And, one last question: right now we're using the EDU-RC to do our development, can we use WPILib with the EDU-RC as long as we use the 18f8520user.lkr file?

Your efforts are greatly appreciated.

[michael714]

Dear Brad,
I've been trying to do it myself. I added the 2k5 files including API.h, UserAPI.h, and WPILIb2k5.lib to Kevin Watson's edu_camera code and the compiler was able to do everything with no errors or warnings except from the Linker at the end and it looked like this:

Error - section 'InterruptVectorLow' type is non-overlay and absolute but occurs in more than one input file.

InterrruptVectorLow is in user_routines_fast.c. I tried removing user_routines_fast.c, but just got another error message. When I comment out the WPILib sample code (from the manual), the error message goes away and everything compiles just fine. As soon as I put the code that references WPILib routines back in, the error comes back. I still have ifi_library.lib attached to the project and I tried removing it, but the error did not go away. I also tried re-ordering the two library files and that did not help either.

Am I trying to do something that can't be done?

[BradAMiller]

Originally Posted by michael714

Dear Brad,
I've been trying to do it myself. I added the 2k5 files including API.h, UserAPI.h, and WPILIb2k5.lib to Kevin Watson's edu_camera code and the compiler was able to do everything with no errors or warnings except from the Linker at the end and it looked like this:

Error - section 'InterruptVectorLow' type is non-overlay and absolute but occurs in more than one input file.

Yeah, that's the crux of the problem. You are seeing that the default code and WPILib each want to control the interrupt vectors. It's pretty easy to write some code that tracks the green target using WPILib, but I think it would be some work to modify Kevin's project to be compatible. You would probably want to use the WPILib camera driver and have it deliver t-packets to his higher level code. It's kind of like trying to run LINUX and Windows on the same computer.

If you are interested in trying to port the code, I'd be happy to help in any way that I can.

WPILib (and easyC) have a different philosophy of device support from the default code, and Kevin's work is based on the default code. In WPILib all the interrupt handling and timing are handled from a single kernel much like an operating system. When other devices want to get interrupt support, either interrupt pins, serial ports, or timers, they just make calls to the kernel to register their "interest". Then when the interrupts happen, the kernal calls the interrupt service routines in the device driver. The reason it works this way is that the device drivers are completely independent of each other. So you could write your own camera driver while leaving everything else unchanged and you wouldn't have to change your application at all.

The default code doesn't work this way - it's a monolithic application that runs on the hardware. To add devices, changes mut be made to quite a few files, rather than just installing a new driver.