Feedback Thread: WPILib

[Nadav Zingerman]

I haven't seen any LabVIEW feedback yet, so I guess I'll be the first.

• The RefNum Registry - I think that this is a bad idea. While it does simplify development by reducing the number of advanced concepts programmers need to know (TypeDefs mostly), it also violates key programming best-practices, such as not using globals unnecessarily. It also discourages a logical grouping of RefNums, such as putting all RefNums for a sub-system in the same cluster.
• Many VIs in the library are not sufficiently documneted (are they even ready for use?) such as the DMA and Interrupt VIs.
• It would be nice if there were support for additional features of joysticks and gamepads, such as tactile feedback (many gamepads have a vibration feature).
• Beta screen shots showed an "Experiment Framework" in addition to the Robot Framework. It would be nice it this were made available again (I'm assuming this is something similar to 2009's Basic Framework) for testing sensors and the like. Right now we open example files and modify them for this purpose.

I don't know where bug reports belong, so I'll report here:

• The DBL Array version of the polymorphic PID block does not work out of the box. It seems to be looking for some DLL. A workaround is to use the LabVIEW implementation by setting the "PIDimplementation" symbol to "G", but this probably hurts performance, and regerdless, not many teams will know to do this.
• The PID Autotuning VI is broken and fails at the autotuning proccess, also searching for a missing file.
• The PID palette exist twice. Once as in the main palette list and once under Control Design & Simulation. The latter contains more functions, some of them quite useful, so it's a shame to have them hidden away in a submenu. Besides, duplication is evil.

Overall, great job with WPILib

[Kingofl337]

While this isn't part of WPILib yet, the CANJaguar code, more specifically "BlackJaguar.out" crashes upon momentary disconnect from the network, either due to noise or a connection issue. Most communications protocols can handle a brief disconnect.

[jhersh]

Originally Posted by Kingofl337

While this isn't part of WPILib yet, the CANJaguar code, more specifically "BlackJaguar.out" crashes upon momentary disconnect from the network, either due to noise or a connection issue. Most communications protocols can handle a brief disconnect.

Please file a bug report at FIRST Forge so this can be addressed. Please include as much detail as you can.

Thanks,
-Joe

[FRC4ME]

Originally Posted by Kingofl337

While this isn't part of WPILib yet, the CANJaguar code, more specifically "BlackJaguar.out" crashes upon momentary disconnect from the network, either due to noise or a connection issue. Most communications protocols can handle a brief disconnect.

We experienced the same problem. In the end we had to stop using CAN on the competition bot, because the entire drive system thread would crash if it lost a single packet. With the heavy vibrations and impacts of competition shaking the connectors around in the CAN ports, this happens sometimes.

[jhersh]

Originally Posted by FRC4ME

We experienced the same problem. In the end we had to stop using CAN on the competition bot, because the entire drive system thread would crash if it lost a single packet. With the heavy vibrations and impacts of competition shaking the connectors around in the CAN ports, this happens sometimes.

I hear you. I intend to make it a lot more forgiving before next season. However, I haven't seen any "crashes"... can you explain in detail what you are seeing by creating a tracker over at FIRST Forge?

Thanks,
-Joe

[Radical Pi]

Originally Posted by FRC4ME

We experienced the same problem. In the end we had to stop using CAN on the competition bot, because the entire drive system thread would crash if it lost a single packet. With the heavy vibrations and impacts of competition shaking the connectors around in the CAN ports, this happens sometimes.

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.

[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!");
}
}

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