What was the hardest to program this year in Java?

I was going around, and I know that people make classes/interfaces for doing the bizzare things that are used frequently on their robots.

For me is was getting DigitalInputs working, to do that, I made this class:

package com.shadowh511.mayor.inputs;

import edu.wpi.first.wpilibj.DigitalInput;

public class Switch {
    private DigitalInput source;

    public Switch(int channel) {
        this.source = new DigitalInput(4,channel);
    }

    public Switch(int slot, int channel) {
        this.source = new DigitalInput(slot,channel);
    }

    public boolean oldGet() {
        return this.source.get();
    }

    public boolean get() {
        if(!this.source.get()) {
            return true;
        } else {
            return false;
        }
    }
}

what you use to call this is:

Switch ballSwitch = new Switch(4);

or

Switch ballSwitch = new Switch(4,4);

I recommend the bottom one just to be on the safe side.

For us it’d have been making our own Gyro code. We used three gyros on the robot and so had to make our own. It ended up being just as accurate as the WPI code and now we are adding some filtering to it to solve for irregularities.

I gave up on the gyro after 3 hours

I think the hardest part for us was working with the Cypress I/O board. I can’t count the number of times I got the “Enhanced IO Missing” exception while trying to read inputs from that thing. It turns out you can’t read them in robotInit() - you have to wait about a second for the board to be ready before attempting to read it.

I hated that too.

I used a seperate class for the cypress i/o module (com.shadowh511.mayor.inputs.DomBoard) that did all the work by itself.

Some issues we had included:

  1. Getting the cRIO not to throw random exceptions when using known working code (gotta love that cRIO imaging tool…)

  2. Getting our drivetrain working (and not curving). We ended up scrapping RobotDrive and implementing our own Drivetrain class.

  3. Making sure we didn’t lose communication.

Oh, and I forgot to mention: finding and fixing bugs in WPI’s code. :stuck_out_tongue:

So far we’re overriding three of WPI’s classes with our own versions: PWM, because someone forgot to cast two integers to doubles before dividing them; Encoder, because someone divided by 0.25 when they should have divided by four; and DriverStation, because the scaling on the joystick axes is wrong (it goes from -1.0 to 0.9 rather than -1.0 to 1.0 due to the use of two’s complement).

Not that I’m complaining; when volunteers write 20,000 lines of code there are bound to be a few errors. In fact, I’m glad WPILib isn’t perfect, because then my programming team would have nothing to do after week one. :slight_smile:

It was actually student voulenteers

The hardest and most frustrating is debugging… But a lot of times, it ended up being electrical that was messed up… e.g. IR Sensor not lined up, Pressure sensor not wired up correctly, and ect

Was anyone else having a problem getting the debugger to work?

The hardest part of programming is always convincing everyone that it’s not a code problem! Fine, it was twice, when someone accidentally would comment out `break;’ on one-line cases in switches.

Things we did abstract farther:
Our side kicker was incredibly complex. So, I created a the hardware.SideKicker' class that made it work work like ``sideKicker.set(SideKicker.Mode.kLoad);''. It had 4 states: kick, load, close, and wait (which are normally run in that order). Beside that, I further broke the kicker down into thehardware.sideKicker.Loader’ and hardware.sideKicker.Latch', both of whichhardware.SideKicker’ used. Even after that, all the timing logic and such is still fairly complex, but I did manage to make it pretty zen.

Same thing with the front kicker, although it is a lot more straight forward (kick and load), no timer issues other than the 2 second rules of the competition.

We also further abstracted the driverstation ``LCD’’.

  • LCD.lines[0-5] is an array storing the desired text.
  • LCD.update() updates the hardware based on the array, adding spaces if necessary (having parts of long numbers left over can be very
    confusing when debugging a problem).
  • LCD.println(str) adds a line, scrolling the other lines (this changes the array, and runs LCD.update()

to be honest, i stole my team’s driverstationlcd class from the Comet’s code

Hah, I think the most complex thing in my code was the kicker stepping system, though the order processing system wasn’t all that simple either. Of course the autonomous handler and the stepping manipulator building-blocks system were way more complicated but those were disabled in the competition version of the code. This was simply because I had to finish them after shipping and the mentors didn’t want untested code in competition. In regard to WPI crap, I ended up doing a bunch of extensions just so I would have my own inheritance tree to play with, and I had to fix some bugs along the way.

Oh and speaking of shifting the blame away from programming, I had some serious issues with that. For two days at our regional the robot didn’t move on the field. It worked just fine in the pit, tethered and it worked fine at school on wireless. Eventually I solved the problem by reimaging the cRIO, but that was after the mentors had ordered me to remove the Java code I wrote and replace it with the default LabView code. (There was a lot of fighting about this. Apparently someone from another team that used Java but switched to LabView came over and said that the Java code was the problem.) Unfortunately, this whole mess has now prevented us from going to Atlanta, although we’ve already paid the fee…

Interesting, because something similar happened, except by willingness of I. I have the robot coded in not just java, but in Labview as backup (boredom produces somewhat valuable things sometimes). Since I never had time to test either code before the robot was shipped, I scrapped the java code and perfected the Labview code. It was sad to see 4 days of hard work go to waste and STILL nothing worked (NOTE: it was not a code error that killed our robot, someone just wired all pwms backwards).

As for the actual question, hands down our parallel kicker. It wasn’t the code itself, but the implementation and lag prevention that was very difficult.

i solved a similar lag problem with a kicker thread

I wouldn’t go so far as to call it “crap.” Were you around in the days of IFI? The default code didn’t really have bugs in it - I’ll give you that - but its organization didn’t make much sense. Lines like “extern volatile near unsigned long short VAR” were not uncommon, and many teams ended up using Kevin Watson’s unofficial default code instead.

When I was on a high school, I wrapped all of WPI’s classes as well. In fact, I’m beginning to wonder if that’s what they want you to do. Let WPI handle the low-level hardware drivers and interactions with the FPGA, but write the high-level inheritance tree yourself.

Mecanum drive was also up there

One thing that frustrated us was the 21 character limit for the User Message box in the Dashboard DriverStationLCD. I know that it’s a holdover from the old system, but it would have been nice to be able to change that limit for the new driver station LCD. After reading the posts here, it sounds like it might have been possible to write a new class to override the limit, but as relatively beginner Java programmers, it was not entirely obvious.

Another bummer was the DefaultCode template. The Timer.delay() routine was not as useful as we thought it would be. We needed delays because of how our pneumatic kicker was designed, but we wanted the teleop periodic to keep looping as well. Timer.delay() did not allow that to happen. Eventually, we learned that we should have put our pneumatic code into a thread that is separate from our joystick read and motor control. But working with threads will be something new for our team. It would be nice to have a sample routine with some task in its own thread.

It wasn’t very friendly that the DefaultCode template tells you that you should not use it. We understood not to use it as-is, but the comment at the beginning of the template was a bit offputting. A bit more commenting throughout would also be helpful- I’m going to send my suggestions to the folks at WPI. One specific point was the disable mode. Didn’t understand when and how it could be used until shortly before the competition. Finally discovered that it allowed us to use the driver station to set our autonomous mode and that was very helpful.

Not directly related to Java, the Driver Station update process was frustrating. The deal about having to install, then uninstall, then reinstall was frustrating. And somehow we downloaded what we thought was the latest update, but when we got to the competition, we were told that it was not the latest update. They point to a date on the dashboard, but this indication was not described in any readme or release notes for the driver station update.

We did most of our debugging via System.out.println statements, but it seemed like occasionally those statements directly interfered with other code- no specific example at this time. Just curious if anyone else noticed that.

The WPIlib user guide for Java was not complete and so there were some things we wanted to know but were not described in the document.

When we tried to receive data from the NXT Magnetic Compass, we received an error message along the lines of “Invalid Manufacturer.” Not sure if that was a Java problem or something else.

Had some problems getting digital inputs to show up on the dashboard using the Dashboard example code. The analog inputs showed up fine, but not the digital inputs.

Not sure why writing data to the DriverStationLCD was so time consuming, but we experienced that and noticed that others have made posts about it as well.

Things that we loved:

  • The gyro class worked quite smoothly
  • Being able to set autonomous mode via disabled mode was cool
  • The Java was much easier to work with than Labview for those of us who have written code using text for years
  • It was quite easy to implement holonomic drive code and it was beautiful to see the result
  • Although I have my complaints about the DefaultCode template, in the end, we did write code that worked and we did implement our first successful autonomous code in 4 years (scored a goal in autonomous from the middle zone!)

Have you reported all the bugs you found so that the library can be improved for everyone? Even better would be patches that implement the fixes.

Visit http://firstforge.wpi.edu/sf/tracker/do/listTrackers/projects.wpilib/tracker to report bugs!

Thanks,
-Joe

Does the Java tracker actually get used? I noticed that, unlike the C++ tracker which has twelve bugs, the Java tracker only has one; the one that I submitted this January and has still not been fixed. Perhaps this is because, at least when I submitted that one, no Java developers’ names were in the assignment list (only C++ and LabVIEW).

I will gladly fix them myself if that is possible. Can you explain further what the process of submitting a patch is? Thanks.

EDIT - I went ahead and submitted the other bugs to the tracker anyway.