Compact rio not being able to use C

[BradAMiller]

Originally Posted by Mike Mahar

How close is the new library to existing WPILib? I want to get my team up and running as soon as possible and I was wondering if it is worth it to learn the old WPILib on the old controller?

The new WPILib represents the same level of abstraction as the old library. By that I mean that there are methods to run motors, get sensor values, and interact with the driver station. The philosophy has been to stop short of providing code to do the "trick" that is required in any competition, but to make sure the pieces are there so that it's fairly straightforward for a team to do it. For example, there was never any code to drive a robot to a green target, but you could always get the position of the target, and you could always drive the robot. The complete program to follow someone walking around with a green light was less than 20 lines of code.

In other words, using the old WPILib will give you and your team a feel for how to write robot programs with the new library. But the new library will be much more capable and the interfaces much richer than ever before.

And besides all that, the source code will be available along with extensive documentation to make the transition as smooth as possible. We are very sensitive to the fact that a lot of new stuff is getting rolled out at the same time and FIRST is trying to make this as easy as possible.

Brad

[slavik262]

Originally Posted by Nibbles

There is no reason not to use the OO interface using C++, it is simpler, memory management becomes easier, and error handling with Exceptions improves code cleanliness. Unfortunately, if we go all out on C++ (as opposed to using OO and Exceptions sparingly), it makes it difficult to write plain old C if you are intent on doing your own memory management and error handling.

We aren't working with kernels or doing data mining or multi-threading, and are working on a UNIX-like OS (thankfully), so C++ imo is perfectly adequate. I am more worried about people not being able to deal with malloc and free, say, in C more then I am the OO features of C++. OO is pretty simple to grasp if you are only using it.

While I am slightly afraid of what some people will do with malloc and free, I'm looking forward to them. I've already combined OO with some memory management and have some data structure classes ready to implement the second I get my hands on this. And I'm not quite sure what you're saying in regards to OO and exception handling. Why use them sparingly? Once you become versed in C++ they are both extremely useful.

[Alan Anderson]

Originally Posted by slavik262

While I am slightly afraid of what some people will do with malloc and free, I'm looking forward to them. I've already combined OO with some memory management and have some data structure classes ready to implement the second I get my hands on this.

I'm curious to know how you intend to use dynamic allocation in the context of a FRC robot. Perhaps I'm too ingrained in the "embedded system" paradigm to see a good reason not to account for all the data in advance.

And I'm not quite sure what you're saying in regards to OO and exception handling. Why use them sparingly? Once you become versed in C++ they are both extremely useful.

It seems to me that overuse of a language's exception-handling features is a lazy habit. Again, when working with embedded systems, one tends to learn to keep very tight control over unusual situations. My experience is that compiler-level exceptions are not appropriate if you take care to ensure the proper input conditions and to handle out-of-range values explicitly.

[Pat Fairbank]

I'm not a big fan of C++ exceptions - they're hard to use properly, and not very safe. In fact, their use is banned by the two companies that I've worked for that use C++ (Sony, Google (for these reasons)).

On an embedded system, what's going to happen if a thrown exception is not handled properly? The program is going to terminate, which leaves you with nothing running on your robot controller (and this would be very hard to debug).

[Nibbles]

Honestly I can't think of why you would want to use exceptions (or any error handling at all for that matter) on the robot, because it doesn't deal with literal user input. Errors (division by zero) means something wrong in your logic (a case for using assertions), and bad/conflicting input values (both upper and lower limit switches are triggered, say) should be handled when parsed and dealt with then, not inside a function that detects them.

On C++ programs, I only use it for passing down error messages through a large stack of functions, where I know it will be caught (as for the overhead, it can't be any worse then using a scripting language, or a custom-built method of passing down structs of data, but maybe I am just too ignorant). I go by the rule of thumb only add exceptions that you will be catching yourself (don't put them in libraries for other people to use).

[slavik262]

The only reason I would use exception handling is for debugging purposes. I really have no plans on using it in the competition builds. I agree with all people above that it would become a bit of a nightmare to properly handle all exceptions. I am a strong believer in just writing the code well so that exceptions aren't thrown in the first place.

[BradAMiller]

OK, there's a bunch of stuff going on here, let me see if I can give the rationale for some of the design decisions with a disclaimer at the end.

First, something about our new environment. We have about 500x more memory and probably 100x more processor speed 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++ 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 are 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 OperatorControl 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 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.

[Alan Anderson]

Apologies for the length of this post. I have trimmed it significantly from its original form, and it is still much larger than I would like.

Originally Posted by BradAMiller

...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).

I'm not certain what you intended to say here. Doesn't any hardware control task require "precise coding"? There wasn't any "hand optimization" in the interrupt code I wrote, nor was such optimization even an option given the C18 compiler most teams were using. I'm pretty sure you didn't mean that "lots of bugs" are a necessary part of interrupt logic. I'm also wondering how the PIC interrupt logic doesn't count as "dedicated hardware" just because it's on-chip.

In short...huh?

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.

You're apparently mixing a couple of different things here, and neither of them seems relevant. Using Kevin Watson's encoder support library for the IFI control system, when the program wants the number of ticks it just reads the value. The default code indeed does busy-wait polling for A/D conversions, but lots of teams replaced that library with one that uses interrupts -- in short, sampling across as many channels as desired "in hardware".

Is your point that the FPGA makes it possible to support much higher rates of encoder ticks or A/D samples? A faster CPU would be able to do that itself, without FPGA assistance, using interrupts. So speed alone doesn't seem like a compelling argument for eschewing interrupts.

...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...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.

It sounds like you have had a very bad experience with interrupts. That's probably not just because they were interrupts, and more likely the result of badly designed or poorly implemented service routines.

I can honestly say that I have never seen any problems in FRC robot code that I have traced to a "real-time bug". The one I thought I saw (in someone else's code) was eventually determined to be an EEPROM access contention issue, having nothing to do with interrupts, and was experimentally solved by adding a "real-time" feature (i.e. a semaphore) to the program. On the contrary, the big interrupt-related issue I have seen many teams run across is due to the IFI default library's not using "real-time" code for its PWM generator.

Just how are we going to be able to implement PID control -- or even simple speedometers -- without using "real-time" features anyway? That's a question I asked some time ago when it was made clear that the cRIO doesn't have interrupts, and it was never satisfactorily answered.

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.

The reasoning behind this statement eludes me. What am I missing? How is the amount of hardware relevant? Does dynamic allocation (i.e. at run time) address it any better than static allocation (i.e. at compile time)?

[BradAMiller]

Wow, tough crowd!

Alan - if I suggested that interrupts were evil, that wasn't my point and I'm sorry for not making that clear. And I certainly didn't mean to suggest that lots of bugs are a necessary part of interrupt logic. My point was that having dedicated hardware is a good thing and makes programming easier and offloads the CPU running the robot program. But let me try to answer some of your questions directly.

You mentioned that you never received a satisfactory answer on the questions of "speedometers" and PID time-based code.

By speedometers, I'm guessing you were asking about measuring the period of signals from encoders on rotating shafts for measuring motor speed directly, please correct me if that's not what you meant. There will be 8 hardware quadrature encoder inputs and 8 hardware counter inputs. Each of these can track the period as well as the count. The period gives an instantaneous representation of speed. Any digital I/O port can be routed to any of these encoders/counters.

There are many ways of solving your issue with time-based algorithms like PID integration. One is to use the Notification class that will periodically call some function in your program. You can, for example, request notification every 20ms and do the PID calculations there. Even though it is not a true hardware level interrupt routine, the function can get the precise time and easily apply the appropriate weight as it's integrating the error value. There are many additional mechanisms that could be used for solving the same problem.

You asked what i meant by "dedicated hardware" and asserted that it wasn't really necessary and ultimately could just be replaced by faster CPUs.

I believe that having hardware to supplement the CPU is a good thing. Like video cards in PCs - it doesn't matter how fast CPUs get, they'll never be as fast as dedicated pipelined graphics engines we see on modern video cards.

Same is true on the robot. A few years back there was a gear tooth sensor that generated a (about) 40 microsecond pulse for one direction and a (about) 70 microsecond pulse for the other. If the interrupt on the gear tooth sensor occurred while a higher priority master processor interrupt was being handled (delaying the start of the gear tooth sensor interrupt handler) there would be no way of measuring the pulse width. And we couldn't determine the direction. That's an example of where using the CPU just doesn't work. With "dedicated hardware" we can easily know and the program doesn't have to deal with those complexities.

You mentioned Kevin Watson's code with respect to encoders and A/D converters. Kevin was able to accomplish amazing things with PIC chips. He really knew that hardware better than most people I've met and all FIRST teams recognized that.

In his encoder FAQ he talks about about phasing errors caused by limited software sampling and interrupt rates that give false interpretations of encoder direction sensing. This is not a problem when there is dedicated hardware looking at each encoder channel, it's only an issue when the CPU is over taxed with many devices competing for the CPUs resources or encoder rates are too high.

D/A converters can be sampled with software in interrupt routines, and as you pointed out Kevin's interrupt-based example proved that. But we now can achieve about 500k samples/second aggregate rate on each of two modules without the CPU getting involved at all. And that's with hardware oversampling and averaging and integration for gyros. I'm not saying this can't be done without dedicated hardware, but having it sure seems better to me than not having it.

We hope to continue to get input from the FIRST community, make improvements and address concerns as they come up. Please keep asking questions, but please don't shoot the messenger. I for one would prefer to see constructive questions targeted at the hardware/software and not the developers.

[rwood359]

Originally Posted by BradAMiller

We hope to continue to get input from the FIRST community, make improvements and address concerns as they come up. Please keep asking questions, but please don't shoot the messenger. I for one would prefer to see constructive questions targeted at the hardware/software and not the developers.

It's difficult to form constructive questions when there are only epic poems and myths about how the new hardware and software are going to work. There is more detail in your last post than in all preceding posts and announcements that I have seen.

Can you give us an ETA for the WPILib manual?

Will it be released to all teams at once or only to the beta teams and later to the rest of us?

edit - added questions:
Can you tell us which Wind River Tools will be available?
Will the source code be released with the manual?
Will there be details such as

Originally Posted by BradAMiller

But we now can achieve about 500k samples/second aggregate rate on each of two modules without the CPU getting involved at all. And that's with hardware oversampling and averaging and integration for gyros.

or will there calling sequences to initialize and read the gyros?

Thank you,
Randy Wood

[BradAMiller]

Originally Posted by rwood359

It's difficult to form constructive questions when there are only epic poems and myths about how the new hardware and software are going to work. There is more detail in your last post than in all preceding posts and announcements that I have seen.

My high school english teachers would never believe someone would accuse me of writing epic poetry.

Can you give us an ETA for the WPILib manual?

Will it be released to all teams at once or only to the beta teams and later to the rest of us?

The documentation and source code will be released to the beta teams next week along with the beta development tools. The decision on the rest of the public release is up to FIRST.

edit - added questions:
Can you tell us which Wind River Tools will be available?

The software will include Workbench 3.0 based on Eclipse 3.3. The FIRST program builds use the gnu C/C++ compiler. Full remote debugging (breakpoints, watchpoints, single step, etc.) is included, some of the other profiling tools from the full version of WorkBench are not there. You can debug the program remotely over the Wifi or ethernet connection.

Will there be details such as

or will there calling sequences to initialize and read the gyros?

I'm not sure exactly what you're asking, but there is a class for the gyro. Inside the class the A/D channel hardware is set up to do averaging and oversampling and the output from the A/D conversions is routed to a hardware accumulator that does the integration (summing) to compute heading from the gyro rate output. The software just reads/scales the current value whenever the program asks for it. The hardware has two of those accumulators so you can have two gyros or other devices requiring hardware summed A/D values.

Are those the details you were looking for?

Thank you,
Randy Wood

You're welcome - good questions!

[Alan Anderson]

I have many more comments, questions, and quizzical requests for clarification. I will defer them all until after I've received the opportunity to work with the platform I'm asking about.

Originally Posted by BradAMiller

I for one would prefer to see constructive questions targeted at the hardware/software and not the developers.

As would I. Lacking the hardware/software, however, I have little choice but to aim my questions at the people whom I assume ought to be able to answer.

[The Lucas]

Originally Posted by BradAMiller

There are many ways of solving your issue with time-based algorithms like PID integration. One is to use the Notification class that will periodically call some function in your program. You can, for example, request notification every 20ms and do the PID calculations there. Even though it is not a true hardware level interrupt routine, the function can get the precise time and easily apply the appropriate weight as it's integrating the error value. There are many additional mechanisms that could be used for solving the same problem.

This touches on my primary curiosity:
How will the library implement multitasking and scheduling?
I think this the most significant change in the new system and the real challenge in an RTOS. There is a conflict between ease of programming (learning curve) and advanced functionality. I can see a need to abstract this issue away for the basic users who do not use utilize the CPU enough for it to be an difficult issue. However, the user with heavy vision processing (multi target tracking) and multiple PID loops will need low level access to the scheduling features to ensure deterministic performance.

So in the library, how can the programmer declare a object/method/function as a separate task (process)?

How do you set priority among these tasks? Is it an object attribute?

What about inter process communication? A message class?

Also since Day 1 I have been curious about how the disable/autonomous states will work across the control system as a whole. Specifically, can the driver station communicate with the cRIO in disable mode(as so many teams use to select auto modes)?

Thanks for the info
Brian

[rwood359]

Originally Posted by BradAMiller

The documentation and source code will be released to the beta teams next week along with the beta development tools. The decision on the rest of the public release is up to FIRST.

Please lobby for the have-nots. Some dialog can start as soon as we have the documentation and tools. Getting some things cleared up now may reduce your work load when everyone gets the full system.

The software will include Workbench 3.0 based on Eclipse 3.3. The FIRST program builds use the gnu C/C++ compiler. Full remote debugging (breakpoints, watchpoints, single step, etc.) is included, some of the other profiling tools from the full version of WorkBench are not there. You can debug the program remotely over the Wifi or ethernet connection.

This sounds like fun! I have some concerns about breakpoints and motors. Are breakpoints tied into the FPGA to pause PWMs?

I'm not sure exactly what you're asking, but there is a class for the gyro. Inside the class the A/D channel hardware is set up to do averaging and oversampling and the output from the A/D conversions is routed to a hardware accumulator that does the integration (summing) to compute heading from the gyro rate output. The software just reads/scales the current value whenever the program asks for it. The hardware has two of those accumulators so you can have two gyros or other devices requiring hardware summed A/D values.

Are those the details you were looking for?

Thanks for the information on the gyros. My real question is about the level of documentation of the FPGA that is sitting between the code and the devices. One of your earlier posts in this thread described both specific device interfaces and generalized tools to build an interface. How detailed as to timing and timing constraints will the documentation be?
For example, in your response above, you described the functionality of the gyro driver without giving any data rates. Will the functional document have the data rates for the sampling and such? You don't need to give details here.

Thanks again,
Randy Wood

[BradAMiller]

Originally Posted by The Lucas

This touches on my primary curiosity:
How will the library implement multitasking and scheduling?
I think this the most significant change in the new system and the real challenge in an RTOS. There is a conflict between ease of programming (learning curve) and advanced functionality. I can see a need to abstract this issue away for the basic users who do not use utilize the CPU enough for it to be an difficult issue. However, the user with heavy vision processing (multi target tracking) and multiple PID loops will need low level access to the scheduling features to ensure deterministic performance.

We are hoping to do some classes to help start and manage tasks. It will make it easier to cleanly shut down at the end of the program. Teams may also call the VxWorks functions directly if they desire. One of the challenges for teams choosing to use the multitasking features will be managing priorities and doing synchronization. It can get thorny.

So in the library, how can the programmer declare a object/method/function as a separate task (process)?

In VxWorks you just supply a function that runs as the new task and a bunch of parameters that are passed to it. Our class will do the same thing.

How do you set priority among these tasks? Is it an object attribute?
What about inter process communication? A message class?

VxWorks lets you set the priority on task creation and you can modify it with a function call.

No plans right now for messaging or interprocess communication. Good opportunity for a team contribution.

Also since Day 1 I have been curious about how the disable/autonomous states will work across the control system as a whole. Specifically, can the driver station communicate with the cRIO in disable mode(as so many teams use to select auto modes)?

This is pretty much the same as before - you can read the driver station while disabled. There is a lot of support in the library to help robot programs detect the field state and deal with it.