Feedback Thread: WPILib

[biojae]

Originally Posted by Radical Pi

I've seen nothing like this. On our bot we were running without a jag for a while (thanks to the ID reset bug) while the code was still trying to communicate with it which would surely drop packets. Using C++ w/ black jag bridge.

I have seen this only when using Java.

Instead of a C++ assert that prints on the debug, the java implementation uses an unchecked exception.

Seeing as the exception doesn't have a compile time warning, it is easy to overlook.
If not handled, the exception will kill the main thread thus the bot, which means that one jag failure results in a dead bot.

[kamocat]

Several things I'd like integrated into the WPI library:

1. In "Driver Station Communication.vi", when Analog Input 8 is opened, endorse the refnum registries by setting it as "battery voltage" on the analog inputs. Perhaps even make a "battery voltage" VI that provides the voltage pre-scaled.
   
2. Make the Accelerometer VIs polymorphic to chose between the analog accelerometer and the I2C accelerometer.
   
3. Create an option on the refnum registries to get the whole array of items in that registry. While I could just open it up and modify it, I'd like it included in the WPI library by default, so I can create VIs that use this capability, and distribute them to others.
   
4. I'd also like a square wave signal generator for the digital outputs (done with the FPGA). Perhaps the inputs would be "period", "duty cycle", "# of cycles" OR "on period", "off period", "total time". Even if only two outputs per module can be used for this, I think it would be an excellent feature to encourage custom electronics.

I think all of these things would be pretty simple to implement. I can provide examples if my descriptions are unclear.

[FRC4ME]

Originally Posted by biojae

I have seen this only when using Java.

Instead of a C++ assert that prints on the debug, the java implementation uses an unchecked exception.

Seeing as the exception doesn't have a compile time warning, it is easy to overlook.
If not handled, the exception will kill the main thread thus the bot, which means that one jag failure results in a dead bot.

Yeah. I actually like the Java WPILib's more frequent use of exceptions (so long as they're only used to indicate exceptional situations), but that particular one should probably be checked.

[virtuald]

One thing that particularly annoys me in C++ (but I realize isn't exactly a WPILib problem) is that calling assert() doesn't trigger a breakpoint in the debugger at all -- which really, that is the whole *point* of assert().

[byteit101]

How about more use of the semaphore notification lists (in Axis camera, they "fire an event" when a new image is received)
some areas where that would be nice:
DS new Data
DS send data (dashboard)
limit switch/digital input

It would be helpful if there was a class for these semaphore events (how about SemaphoreEvent?).


It would also be nice if the simple robot (which need a better name, IMO) was threaded, and you could tell it to kill auto if it is taking too long:

class myrobot:public betternameforsimplerobot
{
//..
myrobot()
{
     this->killAutoifItRunsTooLong=true
}

void Auto()
{
while(true)
{
printf("Bwa ha ha! You are stuck in an infinite loop!");
}
}

[kamocat]

Well, I just thought of another thing I'd like to be able to do:
The FPGA is capable of reading inputs at a much faster rate than the processor. Why not leverage this so that the FPGA can be used for short periods of high-speed data collection on the Analog inputs?
Say you configure the sample rate and the number of samples in begin.vi, and then you just use a VI to trigger the collection?

[Ether]

Originally Posted by kamocat

Well, I just thought of another thing I'd like to be able to do:
The FPGA is capable of reading inputs at a much faster rate than the processor. Why not leverage this so that the FPGA can be used for short periods of high-speed data collection on the Analog inputs?
Say you configure the sample rate and the number of samples in begin.vi, and then you just use a VI to trigger the collection?

The FPGA can't collect analog samples any faster than the ADC can digitize them.

~

[Joe Ross]

Originally Posted by kamocat

Well, I just thought of another thing I'd like to be able to do:
The FPGA is capable of reading inputs at a much faster rate than the processor. Why not leverage this so that the FPGA can be used for short periods of high-speed data collection on the Analog inputs?
Say you configure the sample rate and the number of samples in begin.vi, and then you just use a VI to trigger the collection?

Have you looked at the DMA examples?

[kamocat]

No, I don't know what DMA is. I'll look into those now.

How about a boolean latch function? I think this might be possible with the "time since last pulse" counter, but that would require storing how long ago the last pulse was. A latch function might be configurable for "a pulse at least this length" so it could be used on things like switches. (In this past year, it could be used for a kicker passing by a switch to determine if it is at or past the frame perimeter.)

[Joe Ross]

Originally Posted by kamocat

How about a boolean latch function? I think this might be possible with the "time since last pulse" counter, but that would require storing how long ago the last pulse was. A latch function might be configurable for "a pulse at least this length" so it could be used on things like switches. (In this past year, it could be used for a kicker passing by a switch to determine if it is at or past the frame perimeter.)

How about an interrupt (Utilities->Interrupts). You can configure it on a rising or falling pulse (although not on a pulse width). You might even be able to cascade it with a counter to give you what you want.

[jhersh]

Originally Posted by kamocat

How about a boolean latch function? I think this might be possible with the "time since last pulse" counter, but that would require storing how long ago the last pulse was. A latch function might be configurable for "a pulse at least this length" so it could be used on things like switches. (In this past year, it could be used for a kicker passing by a switch to determine if it is at or past the frame perimeter.)

You can use digital filtering to ensure the pulse is at least "x" long. Then you can use an event counter to count each one or an interrupt as Joe suggested. The counter could handle more than one event before being read by your code. The interrupt will give you the time the event happened, but not handle more than one without overwriting the older event. With DMA, you could get both the time and more than one, but there is only one DMA resource available.

-Joe

[LukeS]

Originally Posted by biojae

I have seen this only when using Java.

Instead of a C++ assert that prints on the debug, the java implementation uses an unchecked exception.

Seeing as the exception doesn't have a compile time warning, it is easy to overlook.
If not handled, the exception will kill the main thread thus the bot, which means that one jag failure results in a dead bot.

Since MARC I have created a modified version of the code, to fix this. If you are planning on attending IRI, you may want it.
http://www.chiefdelphi.com/forums/sh...ad.php?t=86289

[spartango]

If there was one part of the WPILib that bothered me, it was that when it got ported to the java platform, it didn't get redesigned to match java paradigms and features. As an example, it doesnt use OOP or exceptions as effectively as it might.

The bigger, and more interesting, feature that seems to be wholly missing from the WPILib is events & asynchronous action. In my experience, these are particularly useful, if not essential, in robotics & other realtime applications...

Case in point, see TinyOS, the embedded development platform where EVERYTHING is event based and asynchronous. The iOS platform also actively demonstrates this system effectiveness.
Developers from my team implemented and successfully used our own event models in java, and I would encourage you to look at their work in improving the WPILib.
http://code.google.com/p/grtframework

[kamocat]

In the LabVIEW version, I'd like the refnum registries more tightly integrated with the act of opening and closing references for diagnostic purposes, so that when a reference is opened twice, the second time it will state for what purpose that channel was originally opened.
I realize that it's only as good as the naming, but I think it's a good attempt to aid in diagnostics and troubleshooting.
(For that matter, it'd be neat to automatically start the execution trace tool when the watchdog starts timing out in Teleop. However, I think that could impact the performance of the user code.)

But more about the refnum registries:
There are some things that should not require a name, because there cannot be more than one of them. Here's a list:

• Robot Drive
• Watchdog
• DMA
• Air Compressor

In these instances, the name is just another source of error with no benefit. In fact, with these items you should not have to wire to them at all; they can retrieve the single item from the registry.

[Alan Anderson]

Originally Posted by kamocat

There are some things that should not require a name, because there cannot be more than one of them. Here's a list:

• Robot Drive
• Watchdog
• DMA
• Air Compressor

Any time you have more than one motor powering the same mechanism, a "Drive" is useful. The TechnoKats 2009 robot's propeller was driven by two CIM motors, and about halfway through the build someone pointed out that the program would look simpler if we replaced the pair of motor control blocks with a single Drive block in a few places.

There is only one watchdog and only one DMA resource available to the user, but keeping the general scheme intact and avoiding special cases seems worthwhile.

The robot rules customarily permit only one air compressor. The software support is not that limited; you can define as many as you want until you run out of relay outputs.