Chief Delphi - Team 254 Presents: 2015 FRC Code

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Team 254 Presents: 2015 FRC Code (http://www.chiefdelphi.com/forums/showthread.php?t=137843)

Re: Team 254 Presents: 2015 FRC Code

It appears that this build was done on a linux box (the ruby script is VERY linux specific). I have been trying to build the files (following the build method in the buy script) on my Windows machine using Java 8 JDK and ant loaded from the apache site. I have issues when I launch the sim with incompatibilities between 64 and 32 bit images and then with incompatible libraries in the wpilibj. I am doing this outside of eclipse to make sure I can control the build environment.

Has anyone been successful in compiling this under a windows box? If so could you provide any hints on how you did it?

Edit - Here is the transcript to the failure

Code:

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\me\AppData\Local\Temp\libwpilibJavaJNI4190642768369947334.so: Can't load this .dll (machine code=0xb0b0) on a AMD 64-bit platform

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)

        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)

        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822)

        at java.lang.Runtime.load0(Runtime.java:809)

        at java.lang.System.load(System.java:1086)

        at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:53)

        at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:167)

        at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:179)

Thanks

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Jared (Post 1491882)

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

Code:

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.

Yeah, this is a bug that didn't happen to affect our particular port layout. Good catch.

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by feverittm (Post 1491985)

I ran it under windows doing the steps manually. Here's how:

Make sure you have the 32 bit jvm and jdk on your machine. Also, make sure your PATH variable points to the a 32 bit java 8 jdk/jre. To check run "java -d64 -version" and you should see an error that 64 bit is unsupported. Also run "javac -d64 -version" and you should get the same error message.

Download the three repositories (FakeWPILib, FRC-2015, Sim-FRC-2015) using the download zip option from the github page. Unzip them all to the same folder.

In FakeWPILib/src/edu/..../Solenoid.java, edit the constructor so it looks like the code below

Code:

public Solenoid(final int moduleNumber, final int channel) {

        m_channel = channel;

        initSolenoid((moduleNumber * 7) + channel);

    }

In FRC-2015/src/com/team254/util/lib/MultiLooper.java, edit the constructor so it looks like the code below

Code:

public MultiLooper(String name, double period, boolean use_notifier) {

        if (use_notifier) {

            looper = new Looper(name, this, period);

        } else {

            looper = new Looper(name, this, period);

        }

    }

Open a command prompt window, and go to the FRC-2015 directory.
Run 'ant jar'
Make sure you see BUILD SUCCEEDED

Go to the FakeWPILib directory, and run ant jar
Make sure you see BUILD SUCCEEDED

Copy FakeWPILib/dist/FakeWPILib.jar to Sim-FRC-2015/lib/
Copy FRC-2015/dist/FRCUserProgram.jar to Sim-FRC-2015/lib/

Go to the Sim-FRC-2015
run ant compile

Delete Sim-FRC-2015/tmp if it exists
Copy FRC-2015/dist/FRCUserProgram.jar to Sim-FRC-2015/tmp (create tmp folder)

Create folder classes in tmp
Open command prompt window in classes, run 'jar -xf ../FRCUserProgram.jar

copy contents of FakeWPILib/bin/ to Sim-FRC-2015/tmp/classes, don't use command prompt for this, and be sure to merge folders and overwrite without rename when there are conflicts

copy contents of Sim-FRC-2015/bin/ to Sim-FRC-2015/tmp/classes, same way as before

open a command prompt window in Sim-FRC-2015/tmp
run 'jar -cmvf classes/META-INF/MANIFEST.MF to_sim.jar -C classes .'

to run simulation, run 'java -jar to_sim.jar'

To see the robot graphs, go to localhost:5800 in your browser.

If you get an error, post it here, and I can probably help.

Re: Team 254 Presents: 2015 FRC Code

In DCMotor, is getPosition() in radians and getVelocity() in radians/second?

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Thad House (Post 1492043)

In DCMotor, is getPosition() in radians and getVelocity() in radians/second?

Yes.

The sim is super rudimentary, incomplete, and there are some bugs - but we found it enormously useful for designing the controllers for our elevator and motorized can grabber.

The first time we ran our elevator trajectory controller on the actual robot, it just worked. For the can grabber, we used our model to choose an appropriate gear reduction for the gearbox and evaluate different types of stored energy assist.

No promises, but we will probably continue to work on refining the sim interface and the underlying physics models for next year (for example, in all of our experiments we observe a delay in motor movement that we cannot model, even if we consider inductance). Maybe we'll do a Championship Conference presentation on simulation...?

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Jared Russell (Post 1492049)

... (for example, in all of our experiments we observe a delay in motor movement that we cannot model, even if we consider inductance)...

I keep wondering if it is a combination of inductance, PWM output delay, and talon delay. It would be fun to track that down with an oscilloscope some time.

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Jared Russell (Post 1492049)

No promises, but we will probably continue to work on refining the sim interface and the underlying physics models for next year (for example, in all of our experiments we observe a delay in motor movement that we cannot model, even if we consider inductance). Maybe we'll do a Championship Conference presentation on simulation...?

I'm curious...
The delay... is it around 100-400ms... and is there a load applied to the motor?

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by JamesTerm (Post 1492217)

I'm curious...
The delay... is it around 100-400ms... and is there a load applied to the motor?

I don't recall the measurement, but it was definitely less than 100ms. We had an LED hooked up to the speed controller output and used 240 fps video and frame counting for speed measurements between the LED going on and the beginning of visible motion (so delay in switching of the speed controller is not the culprit). We've seen this phenomenon occur with both loaded and unloaded motors (I mean, there's always a load, but you know what I mean). For most FRC applications, this is not a big deal, but when trying to shave milliseconds off a can grabber, it was a huge factor.

We tried modeling things like motor inductance, gear train/motor drag, multiple sources of inertial load, and battery/wire voltage drop, but haven't been able to isolate the culprit. Like Austin said, it is probably worth running some experiments.

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Jared Russell (Post 1492220)

We observed the same delays during our testing.

Our model matched the shape and time of the response very well, but was time shifted over.

An interesting test would be wiring a motor + LED to run directly off a main breaker, and see how much the delay is reduced there.

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by AdamHeard (Post 1492228)

Yeah. One possibility is an inductance/current ramping in the speed controller. This would cause the LED to light almost immediately, but the motor would be slow to generate torque.

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by Jared Russell (Post 1492231)

Yeah. One possibility is an inductance/current ramping in the speed controller. This would cause the LED to light almost immediately, but the motor would be slow to generate torque.

Any chance this is due to backlash in the geartrain?

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by DampRobot (Post 1492235)

Any chance this is due to backlash in the geartrain?

It's not - there is no visible motion in the geartrain or rotors, and happens even if you preload the transmission so the backlash is on the right side at start.

Re: Team 254 Presents: 2015 FRC Code

On a slightly different note, I found this LIDAR class in your code, but it doesn't appear that you use it anywhere else.

What did you plan on using the LIDAR for and why did you end up not using it (or am I just too blind to find it :))? Or was this just something you looked into during build season?

Re: Team 254 Presents: 2015 FRC Code

Quote:

Originally Posted by hf3132 (Post 1492868)

We played around a bit with using the LIDAR-Lite for helping with automating tote loading - knowing when to run the intake, when to raise the elevator to lift a tote, etc. Ultimately, we ended up using a bunch of Sharp IR sensors instead. Way cheaper, easier to interface with, much quicker to respond, and very robust as long as you use them in a "breakbeam"-like application (where you get a sudden large change in input signal rather than trying to estimate range precisely).

Re: Team 254 Presents: 2015 FRC Code

In FRC-2015/src/com/team254/frc2015/CheesyDriveHelper.java

Code:

        if (isHighGear) {

            wheelNonLinearity = 0.6;

            // Apply a sin function that's scaled to make it feel better.

            wheel = Math.sin(Math.PI / 2.0 * wheelNonLinearity * wheel)

                    / Math.sin(Math.PI / 2.0 * wheelNonLinearity);

            wheel = Math.sin(Math.PI / 2.0 * wheelNonLinearity * wheel)

                    / Math.sin(Math.PI / 2.0 * wheelNonLinearity);

        } else {

            wheelNonLinearity = 0.5;

            // Apply a sin function that's scaled to make it feel better.

            wheel = Math.sin(Math.PI / 2.0 * wheelNonLinearity * wheel)

                    / Math.sin(Math.PI / 2.0 * wheelNonLinearity);

            wheel = Math.sin(Math.PI / 2.0 * wheelNonLinearity * wheel)

                    / Math.sin(Math.PI / 2.0 * wheelNonLinearity);

            wheel = Math.sin(Math.PI / 2.0 * wheelNonLinearity * wheel)

                    / Math.sin(Math.PI / 2.0 * wheelNonLinearity);

        }

What led you to use sin functions like this to scale your steering? Was it just trial-and-error, or was there some method to it?

Also, in the same code file, could you explain what you do with "negative inertia" better?