Team 254 Presents: 2015 FRC Code

[Thad House]

Whats the license like for the code, specifically the stuff in the Simulated Robot Hardware repository. I would like to put some of that in the simulator side of the C# project if possible.

[Tom Bottiglieri]

Originally Posted by Thad House

Whats the license like for the code, specifically the stuff in the Simulated Robot Hardware repository. I would like to put some of that in the simulator side of the C# project if possible.

I added some license files to all the repos (MIT for all our stuff, BSD as some of the FakeWPILib is derivative of WPILib). Feel free to add whatever you see fit to your projects!

[Tom Bottiglieri]

Originally Posted by thatprogrammer

Some questions (not a very advanced programmer, yet)
1. How do you run autonomous mode despite the looper? If you tried your approach on a normal iterative robot template, the loop would run on the wait commands, preventing it from advancing.
2. You need to generate splines to create paths for motion profiling, right?
3. What is the peacock motor?
Some more questions, but I'll wait for answers to to these first.

1. We run the auto in a separate thread. The main thread of the robot which handles iterative updates does nothing in auto mode because all of the marshaling done by the auto modes is done in another thread, and all of the control loops run in a different thread.

2. We didn't use any spline paths this year. All of the control loops were 1d (elevator carriages, drive forward, turn in place). All of the moving subsystems shared a generic base controller which could be tuned for the properties of that system. The motion profiling was done on the fly (this is a much easier calc than generating spline-y paths).

3. The original concept for our can grabber was a system that had 4 individual telescoping arms (feathers) that would go out and grab each can in auto, all starting from the robot centered on the field. This made the robot look like a peacock, and the name for that subsystem stuck through iterations. A motor peacock is just the motorized can grabber assembly.

[thatprogrammer]

Thanks for the replies.
Few more questions.
1. How much smaller/larger than your shafts/stock is the tubing you get from mcmaster to ensure a super snug fit? (NOT a code question, I know )
2. Any reason you chose not to use CAN control for your motors?
3. Did you ever figure out the timing issues java had?

[Jared Russell]

Originally Posted by thatprogrammer

Thanks for the replies.
Few more questions.
1. How much smaller/larger than your shafts/stock is the tubing you get from mcmaster to ensure a super snug fit? (NOT a code question, I know )
2. Any reason you chose not to use CAN control for your motors?
3. Did you ever figure out the timing issues java had?

#1 I can't help with...

#2, the CAN-enabled Talon SRX was new to FRC this season, so we decided to stick with tried-and-true PWM in case there were teething problems. As it turned out, the CAN Talon works great, and I'd say there's a good chance we use them next year.

#3, yeah. The WPIlib JAR we used was tweaked to enable interrupts and the hardware timer to work correctly in Java (basically we just finished some incomplete JNI work). The source of the modified JAR is in the lib directory. Garbage collection and the JVM still mean that we aren't quite as reliable as a RT C++ thread would be, but it is pretty stable with our changes.

[Abhishek R]

Originally Posted by Tom Bottiglieri

3. The original concept for our can grabber was a system that had 4 individual telescoping arms (feathers) that would go out and grab each can in auto, all starting from the robot centered on the field. This made the robot look like a peacock, and the name for that subsystem stuck through iterations. A motor peacock is just the motorized can grabber assembly.

How early in the season did that idea come to inception?

[Tom Bottiglieri]

Originally Posted by Abhishek R

How early in the season did that idea come to inception?

We had some sketches of this day 1 of build.

[M3rcuriel]

Last year, you guys squared turn inputs when you were quickturning (in teleopPeriodic). I don't see it this year - what happened to that?

[Tom Bottiglieri]

Originally Posted by M3rcuriel

Last year, you guys squared turn inputs when you were quickturning (in teleopPeriodic). I don't see it this year - what happened to that?

This robot drove very differently than past robots. It was quite tall and had omni wheels on the corners. We had to mess with the drive code a bit to get it back to a place where the driver felt comfortable. I think his complaint was quick turn was a bit hard to control and would go from zero to full spin too fast.

[Jared]

I'm a little confused with the simulator. FakeWPILib replaces classes that won't run on a computer, but it doesn't have a replacement class for NotifierJNI, which won't run on a computer. NotifierLooper uses NotifierJNI, which creates an unsatisfiedlinkerror exception.

[M3rcuriel]

Another question: what, conceptually, is a Tappable?

[Jared]

I think there's a bug in the solenoid.java file of FakeWPILib

public Solenoid(final int moduleNumber, final int channel) {
        m_channel = channel;
        initSolenoid((moduleNumber * 7) + channel);
    }

Module 0, channel 7 will have an index of 7 as expected, but module 1, channel 0 will also have an index of 7. It should be moduleNumber*8 + channel, not 7.

Something is a little weird - the robot code can't work in the simulator with this version of FakeWPILib, which is also missing a NotifierJNI class. Perhaps there was another revision of FakeWPILib?

[DampRobot]

Originally Posted by thatprogrammer

1. How much smaller/larger than your shafts/stock is the tubing you get from mcmaster to ensure a super snug fit? (NOT a code question, I know )

Not on 254, and it's been a few years, but when we build in intake with BBD in the 2013 offseason, we bought 1/2" ID tubing to go over 1/2" VP hex. There was plenty of interference, and it wasn't impossible to get on (although it was definitely hard). I've heard 254 transitioned from BBD to surgical recently though, so take my experience with a grain of salt.

[Travis Covington]

Originally Posted by DampRobot

Not on 254, and it's been a few years, but when we build in intake with BBD in the 2013 offseason, we bought 1/2" ID tubing to go over 1/2" VP hex. There was plenty of interference, and it wasn't impossible to get on (although it was definitely hard). I've heard 254 transitioned from BBD to surgical recently though, so take my experience with a grain of salt.

We only used surgical tubing in 2014, as it gripped the ball better than the urethane and was way cheaper and came in thinner wall thicknesses. There is no rule for how much larger we go on tubing vs the shaft/driven tube size. We have not used the urethane directly on a non-hollow shaft since 2013. In 2014 we used thin wall aluminum tube with the surgical tubing over it. This year we made some custom wheels with large OD aluminum hubs and huge urethane tubing parted to the widths we wanted. Worked well.

[Tom Bottiglieri]

Originally Posted by Jared

I'm a little confused with the simulator. FakeWPILib replaces classes that won't run on a computer, but it doesn't have a replacement class for NotifierJNI, which won't run on a computer. NotifierLooper uses NotifierJNI, which creates an unsatisfiedlinkerror exception.

We implemented the Notifier after we were done with the sim. We'll get a patch out or if someone wants to patch it, feel free to send a PR.

The fake wpi lib is by no means complete. We just implemented hardware abstractions as we went along and needed them.