Feedback Thread: WPILib

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

[kamocat]

Here's some more ideas for improvement of the FRC LabVIEW framework:

• Put functional tasks in places where it says "you could put your code here" (For example, in timed tasks, you can put code that tracks the current location of the robot using the encoders and gyro. I can make code for this if you're interested.)
• Display joystick axis and buttons on front panel of Disabled.vi (great for troubleshooting. The joysticks can be tested without the robot being enabled.)
• Create a VI that can be used anywhere in the user code to tell the current state of the robot. There's several ways of doing this:
  • Put "Robot Mode" on the functions pallette
  • Change connector pane of the "Watchdog Status" VI to not require the watchdog ref as an input (make it recommended)
  • Create a seperate lightweight version of "Robot Mode" without the extra logic (Really this would just be taking the small section of "Robot Mode" that determines enabled/disabled and teleop/autonomous, and making it a subVI on the functions pallette)