Skip to main content

What is the WPI Robotics Library


The WPI Robotics library is a set of C++ classes that interfaces to the hardware in the FRC
control system and your robot. There are classes to handle sensors, motors, the driver
station, and a number of other utility functions like timing and field management.

The library is designed to:

 • Deal with all the low level interfacing to these components so you can concentrate on
solving this year’s “robot problem”. This is a philosophical decision to let you focus
on the higher level design of your robot rather than deal with the details of the
processor and the operating system.
• Understand everything at all levels by making the full source code of the library
available. You can study (and modify) the algorithms used by the gyro class for
oversampling and integration of the input signal or just ask the class for the current
robot heading. You can work at any level.
First, something about our new environment. We have about 500x more memory and 40x
faster for fixed point and even faster for floating point over the PIC that we're used to using.
The past years high speed sensor-interrupt logic that required precise coding, hand
optimization and lots of bugs has been replaced with dedicated hardware (FPGA). When the
library wants the number of ticks on a 1000 pulse/revolution optical encoder it just asks the
FPGA for the value. Another example is A/D sampling that used to be done with tight loops
waiting for the conversions to finish. Now sampling across 16 channels is done in hardware.
We chose C++ as a language because we felt it represents a better level of abstraction for
robot programs. C++ (when used properly) also encourages a level of software reuse that is
not as easy or obvious in C. At all levels in the library, we have attempted to design it for
maximum extensibility.

There are classes that support all the sensors, speed controllers, drivers station, etc. that
will be in the kit of parts. In addition most of the commonly used sensors that we could find
that are not traditionally in the kit are also supported, like ultrasonic rangefinders. Another
example is several robot classes that provide starting points for teams to implement their
own robot code. These classes have methods that are called as the program transitions
through the various phases of the match. One class looks like the old easyC/WPILib model
with Autonomous and Operator Control functions that get filled in and called at the right
time. Another is closer to the old IFI default where user supplied methods are called
continuously, but with much finer control. And the base class for all of these is available for
teams wanting to implement their own versions.



Even with the class library, we anticipate that teams will have custom hardware or other
devices that we haven't considered. For them we have implemented a generalized set of
hardware and software to make this easy. For example there are general purpose counters
than count any input either in the up direction, down direction, or both (with two inputs).

They can measure the number of pulses, the width of the pulses and number of other

parameters. The counters can also count the number of times an analog signal reaches
inside or goes outside of a set of voltage limits. And all of this without requiring any of that
high speed interrupt processing that's been so troublesome in the past. And this is just the
counters. There are many more generalized features implemented in the hardware and
software.
We also have interrupt processing available where interrupts are routed to functions in your
code. They are dispatched at task level and not as kernel interrupt handlers. This is to help
reduce many of the real-time bugs that have been at the root of so many issues in our
programs in the past. We believe this works because of the extensive FPGA hardware
support.
We have chosen to not use the C++ exception handling mechanism, although it is available
to teams for their programs. Our reasoning has been that uncaught exceptions will unwind
the entire call stack and cause the whole robot program to quit. That didn't seem like a
good idea in a finals match in the Championship when some bad value causes the entire
robot to stop.
The objects that represent each of the sensors are dynamically allocated. We have no way
of knowing how many encoders, motors, or other things a team will put on a robot. For the
hardware an internal reservation system is used so that people don't accidentally reuse the
same ports for different purposes (although there is a way around it if that was what you
meant to do).

I can't say that our library represents the only "right" way to implement FRC robot
programs. There are a lot of smart people on teams with lots of experience doing robot
programming. We welcome their input; in fact we expect their input to help make this
better as a community effort. To this end all of the source code for the library will be
published on a server. We are in the process of setting up a mechanism where teams can
contribute back to the library. And we are hoping to set up a repository for teams to share
their own work. This is too big for a few people to have exclusive control, we want this
software to be developed as a true open source project like Linux or Apache.

Labels:

Popular posts from this blog

C++ Program to find the sum, difference, product and quotient of two integers

#include <iostream.h> #include <conio.h> void main() {   clrscr();   int x = 10;   int y = 2;   int sum, difference, product, quotient;   sum = x + y;   difference = x - y;   product = x * y;   quotient = x / y;   cout << "The sum of " << x << " & " << y << " is " << sum << "." << endl;   cout << "The difference of " << x << " & " << "y <<  is " << difference << "." << endl;   cout << "The product of " << x << " & " << y << " is " << product << "." << endl;   cout << "The quotient of " << x << " & " << y << " is " << quotient << "." << endl;   getch(); }
Read more

Program of virtual piano

//////////////Tested And Created By C++/////////////////////////////// #include<stdio.h> #include<dos.h> #include<conio.h> #include<stdlib.h> #define SHOW 1 #define HIDE 2 union REGS input,output; class piano {  public:int BIGKEY,MIDKEY,back,border;     piano()//init constructor     {         BIGKEY=15;         MIDKEY=1;         back=7;         border=15;     } }color; void drawpiano(int x,int y); int check_xy(int x,int y); void BOX(int c,int r,int c1,int r1,int col); int initmouse(); void setupscreen(); void pointer(int on); void restrictmouse(int x1,int y1,int x2,int y2); void check_keys(int x,int y); void getmouse(int *button,int *x,int *y); float freq[7] = {130.81, 146.83, 164.81, 174.61,196, 220, 246.94 } ; int n=0,a=4,backcolor=2,exitcode=1; void showbar(int t) {  if(t>65) t=65;  if(t<1) t=1;  textcolor(15);  for(int q=0;q<=t;t++)  {     gotoxy(3+q,4);     cprintf("Û");  } } void main() {  int
Read more

Putimage function in c

putimage function outputs a bit image onto the screen. Declaration:- void putimage(int left, int top, void *ptr, int op); putimage puts the bit image previously saved with getimage back onto the screen, with the upper left corner of the image placed at (left, top). ptr points to the area in memory where the source image is stored. The op argument specifies a operator that controls how the color for each destination pixel on screen is computed, based on pixel already on screen and the corresponding source pixel in memory. c smiling face animation This animation using c draws a smiling face which appears at random position on screen. See output below the code, it will help you in understanding the code easily. C programming code #include<graphics.h> #include<conio.h> #include<stdlib.h>   main() { int gd = DETECT, gm, area, temp1, temp2, left = 25, top = 75; void *p;   initgraph(&gd,&gm,"C:\\TC\\BGI");   setcolor(YELLOW);
Read more