What was the hardest to program this year in Java?

[Robototes2412]

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.

[SavtaKenneth]

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.

[Robototes2412]

I gave up on the gyro after 3 hours

[FRC4ME]

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.

[Robototes2412]

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.

[cybiko123]

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.

[FRC4ME]

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

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.

[Robototes2412]

It was actually student voulenteers

[davidthefat]

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

[cybiko123]

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

[LukeS]

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 the `hardware.sideKicker.Loader' and `hardware.sideKicker.Latch', both of which `hardware.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()

[jhersh]

Originally Posted by FRC4ME

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

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.

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...wpilib/tracker to report bugs!

Thanks,
-Joe

[FRC4ME]

Originally Posted by jhersh

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

[jhersh]

Originally Posted by FRC4ME

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.

Sounds good...

I'm not sure why the Java guys aren't on the list. I can address the issues as well, if you don't find one.

If you fix them yourself, you can attach patchs to the artifacts and we'll apply them.

-Joe

[ksanger]

I joined Mak211 last year, three weeks before the ship date. The night before we had crashed our kicker as members had removed parts to modify without telling me. Kick, (too far), bend the forward bracket and eliminated the encoder so the return to reload the kick went back (too far) and destroyed the sensor telling it to stop. The morning of shipping we rebuilt the kicker.

But the most difficult part was that our position sensors on our four wheel steering kept coming loose. Plus we had no means of adjusting the wheels to a known starting position. After shipping we used a spare Crio to figure out how to make a Can Jaguar go from position control to speed control so we could rotate the wheels while reading the pots and displaying their position on the Dashboard. (Last year we were using C++ and to reconfigure the Cans we needed to destruct them then initialize them in either diagnostic speed mode or run position mode). I don't know if I can destruct them in Java and haven't seen a Java example that enables position mode.

Did I mention that I've never coded for C++ objects before? I have been using C since 1980, and I've only read about C++ before and I don't code for a living. Its amazing that we're teaching students Java for next year. Objects rule. Its going to be a while before I'm confident enough to write my own though. Maybe if I had the source I could modify that, but I haven't found the Java wpilibj source.