Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive (http://www.chiefdelphi.com/forums/showthread.php?t=146303)

Jaci 27-03-2016 10:27

Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Project Link

Pathfinder is an API for Motion Profiling. Give it a few waypoints and some information about your Robot and it will generate a nice smooth trajectory for your robot to follow to avoid jerkiness and keep your robot's autonomous movements accurate.

Pathfinder can generate paths for both Tank and Swerve drive systems, as shown in the images below:



(red = front wheels, blue = back wheels. Drivebase constantly facing forward)

Pathfinder's actual generation code is all written in C, so it's very fast, meaning profiles can be generated on the fly. Pathfinder supports C, C++ and Java currently, and doesn't have any dependencies! Because it doesn't have any dependencies, you can even use it in your non-frc projects if you want to.

Pathfinder can use any type of encoder as a feedback device to keep your robot on track. All the parameters are exposed, so you can run the control loop at any speed you like.

The wiki contains instructions for setup and some demo code for generation and following in both Java and C++.

If you use Toast, it will also work in simulation if you're running Windows or Mac. If you're on linux, you can build and install the library manually with the instructions in the readme.

Special thanks to Austin Schuh, Jared Russel and Tom Bottiglieri for pioneering motion profiling code in FRC, and for giving this wonderful talk. Some of the generation code was inspired by Team 254's 'TrajectoryLib', although heavily modified to be more efficient and to work in C.

Ben Wolsieffer 27-03-2016 12:51

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
This looks really cool! I was just working on integrating 254's TrajectoryLib into our code, but I might try this instead.

I know 254 did trajectory generation off of the robot because it was too slow. I assume that the combination of the faster roboRIO processor and the more efficient C implementation made it feasible to move the generation on to the robot. How long does it usually take to generate the trajectories?

Jaci 27-03-2016 13:00

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1563538)
This looks really cool! I was just working on integrating 254's TrajectoryLib into our code, but I might try this instead.

I know 254 did trajectory generation off of the robot because it was too slow. I assume that the combination of the faster roboRIO processor and the more efficient C implementation made it feasible to move the generation on to the robot. How long does it usually take to generate the trajectories?

I've tested with a rate of 50Hz for the profile update, and with about ~200 generated points it takes roughly 3 seconds to generate on the RoboRIO. This year, I used this to generate the profiles before the match had begun so they were ready at the beginning of auton, by providing it with the defense layout of the field and where my robot is on the field as soon as my driver station had connected. Once the robot had received word of where it was, it would generate the trajectory and hold on to it until Autonomous

Ben Wolsieffer 27-03-2016 16:18

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
What advantages does this have over 254's TrajectoryLib? The trajectory following code seems very similar to 254's, but did you make any changes to the generation algorithm other than rewriting it in C? The main reason I am asking this is that TrajectoryLib seems to fit more easily into my robot code than your library, and I'm trying to decide whether I should switch right now.

Oromus 27-03-2016 20:42

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
What's the advantage to using this over, say, a well-tuned PID loop? I find this quite interesting and I'm considering using this on our robot, but I'm wondering what there is to gain from using it.

Ether 27-03-2016 20:54

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Oromus (Post 1563791)
What's the advantage to using this over, say, a well-tuned PID loop?

Explained here, starting at 14:50



Jaci 27-03-2016 22:06

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1563641)
What advantages does this have over 254's TrajectoryLib? The trajectory following code seems very similar to 254's, but did you make any changes to the generation algorithm other than rewriting it in C? The main reason I am asking this is that TrajectoryLib seems to fit more easily into my robot code than your library, and I'm trying to decide whether I should switch right now.

The most major modification is C rewrite, however the structure has been changed, and some of the more mathematical functions of the library have been optimized.

The main advantages are the speed and portability. Pathfinder will run on either Java or C++ robots, and also has the added support for Swerve Drive. As for integrating it into you robot code, it should be a fairly similar experience to TrajectoryLib

Ben Wolsieffer 27-03-2016 22:24

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1563854)
The most major modification is C rewrite, however the structure has been changed, and some of the more mathematical functions of the library have been optimized.

The main advantages are the speed and portability. Pathfinder will run on either Java or C++ robots, and also has the added support for Swerve Drive. As for integrating it into you robot code, it should be a fairly similar experience to TrajectoryLib

The main reasons I feel it is harder to integrate are the lack of the ability to load trajectories from files and that it assumes that the encoder values are not already scaled to physical units. This second limitation can be easily worked around with some math.

I am curious, though, why you chose to do the tick to distance conversion within Pathfinder. Both the Talon SRX and the WPILib Encoder object will do distance scaling for you, so why didn't you just use that?

My original plan was to have a bunch of pre-generated trajectories and just choose to load the one for our selected autonomous. I have decided to use your library after all, and generate multiple trajectories concurrently in the background. This makes the whole process simpler to manage.

GBilletdeaux930 27-03-2016 22:42

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1563866)
I am curious, though, why you chose to do the tick to distance conversion within Pathfinder. Both the Talon SRX and the WPILib Encoder object will do distance scaling for you, so why didn't you just use that?

Quote:

Pathfinder supports C, C++ and Java currently, and doesn't have any dependencies! Because it doesn't have any dependencies, you can even use it in your non-frc projects if you want to.
Probably for that reason right there.

Ben Wolsieffer 27-03-2016 22:48

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by GBilletdeaux930 (Post 1563879)
Probably for that reason right there.

Dependencies have nothing to do with this. If you are using this library outside of FRC, you can very easily do the distance conversion yourself, but when using it with WPILib, the built in conversion makes things more complicated.

GBilletdeaux930 27-03-2016 23:08

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1563883)
Dependencies have nothing to do with this. If you are using this library outside of FRC, you can very easily do the distance conversion yourself, but when using it with WPILib, the built in conversion makes things more complicated.

I understand what you are saying, but that doesn't make the dependency on WPILib disappear.

artK 28-03-2016 00:01

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1563542)
I've tested with a rate of 50Hz for the profile update, and with about ~200 generated points it takes roughly 3 seconds to generate on the RoboRIO. This year, I used this to generate the profiles before the match had begun so they were ready at the beginning of auton, by providing it with the defense layout of the field and where my robot is on the field as soon as my driver station had connected. Once the robot had received word of where it was, it would generate the trajectory and hold on to it until Autonomous

This is awesome! Do you have any video of this running on your robot during auto?

My one question is why are you generating these 200 points? Because that seems like a lot. Each spline covers about 2", and you have 199 points where the quintic constraints have you driving straight locally (Since the second derivative is zero when it approaches the waypoint in the spline configuration we developed). I suspect this would make the robot drive a little twitchy, especially when trying to turn.

Jaci 28-03-2016 01:26

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1563883)
Dependencies have nothing to do with this. If you are using this library outside of FRC, you can very easily do the distance conversion yourself, but when using it with WPILib, the built in conversion makes things more complicated.

This has been fixed in the latest commit. Now we have a Distance Follower, which ditches the encoder conversion, assuming you are giving it values in meters (or whatever unit you're using everywhere else). The EncoderFollower still exists for people who want to feed it ticks, though.

I've also added File Serialization. It will export as a binary format to save space, or as a CSV file. In C++ this will be the functions in `io.h`. In Java, these functions are under the `Pathfinder` class.

Jaci 28-03-2016 01:32

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by artK (Post 1563922)
This is awesome! Do you have any video of this running on your robot during auto?

My one question is why are you generating these 200 points? Because that seems like a lot. Each spline covers about 2", and you have 199 points where the quintic constraints have you driving straight locally (Since the second derivative is zero when it approaches the waypoint in the spline configuration we developed). I suspect this would make the robot drive a little twitchy, especially when trying to turn.

We don't have a video running auto, in my initial code repo all this was done on a coprocessor (and worked flawlessly on a practice field), however we had some issues with FMS not forwarding ports at the regional I went to, so I turned Motion Profiling off in favor for just a 'go forward for x encoder ticks'.

The reason so many points are generated is because of the nature of the control loop. Each point has a dt value (i.e. how long this control loop iteration lasts before moving onto the next) - in our case, it was 1 / 50. Each iteration (which is timed with the Notifier class from WPIlib) will fetch the next segment and process it.

It is possible to look at the second derivs in order to reduce the amount of points, but that would (at least in the current algorithm) add more time to the actual generation sequence. I can modify the algorithm to correct for this and suffer next to no time overhead. Maybe something to put on my todo list

The path didn't jitter at all, in fact it was very smooth. Turning was very smooth and didn't seem to have any issues

Jared Russell 28-03-2016 10:07

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Cool!

artK 28-03-2016 10:08

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1563963)
We don't have a video running auto, in my initial code repo all this was done on a coprocessor (and worked flawlessly on a practice field), however we had some issues with FMS not forwarding ports at the regional I went to, so I turned Motion Profiling off in favor for just a 'go forward for x encoder ticks'.

The reason so many points are generated is because of the nature of the control loop. Each point has a dt value (i.e. how long this control loop iteration lasts before moving onto the next) - in our case, it was 1 / 50. Each iteration (which is timed with the Notifier class from WPIlib) will fetch the next segment and process it.

It is possible to look at the second derivs in order to reduce the amount of points, but that would (at least in the current algorithm) add more time to the actual generation sequence. I can modify the algorithm to correct for this and suffer next to no time overhead. Maybe something to put on my todo list

The path didn't jitter at all, in fact it was very smooth. Turning was very smooth and didn't seem to have any issues

Sorry for the confusion, I had thought when I first read it that you were using 200 waypoints, which was what had me really concerned.

Ben Wolsieffer 28-03-2016 10:25

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1563960)
This has been fixed in the latest commit. Now we have a Distance Follower, which ditches the encoder conversion, assuming you are giving it values in meters (or whatever unit you're using everywhere else). The EncoderFollower still exists for people who want to feed it ticks, though.

I've also added File Serialization. It will export as a binary format to save space, or as a CSV file. In C++ this will be the functions in `io.h`. In Java, these functions are under the `Pathfinder` class.

Thanks! I'll try it out.

Aero 29-03-2016 18:31

Re: Pathfinder - I broke it
 
I'm having trouble running the creation code on the RoboRIO.
Running Pathfinder.generate under Java crashes the robot code.
Code:

Platform: /Linux/arm/
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGSEGV (0xb) at pc=0xaba27110, pid=4901, tid=3062920288
 #
 # JRE version: Java(TM) SE Embedded Runtime Environment (8.0_06-b23) (build 1.8.0_06-b23)
 # Java VM: Java HotSpot(TM) Embedded Client VM (25.6-b23 mixed mode linux-arm )
 # Problematic frame:
 # C  [pathfinderJNI4167093640070579939.so+0x6110]  pf_trajectory_fromSecondOrderFilter+0x74
 #
 # Core dump written. Default location: //core or core.4901 (max size 2048 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
 #
 # An error report file with more information is saved as:
 # /tmp/hs_err_pid4901.log
 #
 # If you would like to submit a bug report, please visit:
 #  http://bugreport.sun.com/bugreport/crash.jsp
 #

The contents of /tmp/hs_err_pid4901.log are as follows:
Code:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xaba27110, pid=4901, tid=3062920288
#
# JRE version: Java(TM) SE Embedded Runtime Environment (8.0_06-b23) (build 1.8.0_06-b23)
# Java VM: Java HotSpot(TM) Embedded Client VM (25.6-b23 mixed mode linux-arm )
# Problematic frame:
# C  [pathfinderJNI4167093640070579939.so+0x6110]  pf_trajectory_fromSecondOrderFilter+0x74
#
# Core dump written. Default location: //core or core.4901 (max size 2048 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#  http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0xb6705800):  JavaThread "main" [_thread_in_native, id=4903, stack(0xb68b8000,0xb6908000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000000

Registers:
  r0  = 0x00000000
  r1  = 0x00000000
  r2  = 0x00000000
  r3  = 0x00000000
  r4  = 0x00000000
  r5  = 0x00000000
  r6  = 0xd2f1a9fc
  r7  = 0x3f50624d
  r8  = 0x00000352
  r9  = 0xae468d30
  r10 = 0xb6705800
  fp  = 0xb690661c
  r12 = 0x00000000
  sp  = 0xb6906560
  lr  = 0xb6decf9c
  pc  = 0xaba27110
  cpsr = 0x60060010

Top of Stack: (sp=0xb6906560)
0xb6906560:  d2f1a9fc 3f50624d 00000022 00000352
0xb6906570:  0efa29f2 ac1d8b38 aba213d0 ac1d8b38
0xb6906580:  b690662c b6ef31b4 b69065d8 ac1d8c94
0xb6906590:  00000000 00000000 00000005 00000000
0xb69065a0:  00000001 ac1d8b38 ac1d90d8 b6907920
0xb69065b0:  d2f1a9fc 3f50624d 00000000 00000000
0xb69065c0:  00000000 00000000 00000000 00000000
0xb69065d0:  00000000 00000000 00000000 00000000

Instructions: (pc=0xaba27110)
0xaba270f0:  ed9b6b01 ed9b7b03 ee866b07 e51b30b0
0xaba27100:  ee073a90 eeb87be7 ee267b07 e51b302c
0xaba27110:  ed837b00 e3a03000 e50b3010 ea0000f6
0xaba27120:  ed9b7b05 ed9f6b67 eeb47bc6 eef1fa10

Register to memory mapping:

  r0  = 0x00000000
0x00000000 is an unknown value

  r1  = 0x00000000
0x00000000 is an unknown value

  r2  = 0x00000000
0x00000000 is an unknown value

  r3  = 0x00000000
0x00000000 is an unknown value

  r4  = 0x00000000
0x00000000 is an unknown value

  r5  = 0x00000000
0x00000000 is an unknown value

  r6  = 0xd2f1a9fc
0xd2f1a9fc is an unknown value

  r7  = 0x3f50624d
0x3f50624d is an unknown value

  r8  = 0x00000352
0x00000352 is an unknown value

  r9  = 0xae468d30
0xae468d30 is an unknown value

  r10 = 0xb6705800
0xb6705800 is a thread

  fp  = 0xb690661c
0xb690661c is pointing into the stack for thread: 0xb6705800

  r12 = 0x00000000
0x00000000 is an unknown value

  sp  = 0xb6906560
0xb6906560 is pointing into the stack for thread: 0xb6705800

  lr  = 0xb6decf9c
0xb6decf9c: __libc_malloc+0x11c in /lib/libc.so.6 at 0xb6d7a000

  pc  = 0xaba27110
0xaba27110: pf_trajectory_fromSecondOrderFilter+0x74 in /var/volatile/tmp/pathfinderJNI4167093640070579939.so at 0xaba21000



Stack: [0xb68b8000,0xb6908000],  sp=0xb6906560,  free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [pathfinderJNI4167093640070579939.so+0x6110]  pf_trajectory_fromSecondOrderFilter+0x74

[error occurred during error reporting (printing native stack), id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jaci.pathfinder.PathfinderJNI.generateTrajectory([Ljaci/pathfinder/Waypoint;Ljaci/pathfinder/Trajectory$FitMethod;IDDDD)[Ljaci/pathfinder/Trajectory$Segment;+0
j  jaci.pathfinder.PathfinderJNI.generateTrajectory([Ljaci/pathfinder/Waypoint;Ljaci/pathfinder/Trajectory$Config;)Ljaci/pathfinder/Trajectory;+29
j  jaci.pathfinder.Pathfinder.generate([Ljaci/pathfinder/Waypoint;Ljaci/pathfinder/Trajectory$Config;)Ljaci/pathfinder/Trajectory;+2
j  ca.warp7.robot.autonomous.SwagDrive.<init>()V+118
j  ca.warp7.robot.Warp7Robot.autonomous()V+5
j  edu.wpi.first.wpilibj.SampleRobot.startCompetition()V+87
j  edu.wpi.first.wpilibj.RobotBase.main([Ljava/lang/String;)V+330
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0xabb47c00 JavaThread "Timer-0" [_thread_blocked, id=4928, stack(0xaba30000,0xaba80000)]
  0x00013c00 JavaThread "NTListener" daemon [_thread_in_native, id=4927, stack(0xaba80000,0xabac0000)]
  0xac1aa000 JavaThread "FRCDriverStation" [_thread_in_native, id=4921, stack(0xabd96000,0xabde6000)]
  0xb6799400 JavaThread "Service Thread" daemon [_thread_blocked, id=4909, stack(0xada4e000,0xada9e000)]
  0xb6796800 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=4908, stack(0xada9e000,0xadb1e000)]
  0xb6795000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4907, stack(0xadb1e000,0xadb6e000)]
  0xb6773000 JavaThread "Finalizer" daemon [_thread_blocked, id=4906, stack(0xadf60000,0xadfb0000)]
  0xb6771800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4905, stack(0xadfb0000,0xae000000)]
=>0xb6705800 JavaThread "main" [_thread_in_native, id=4903, stack(0xb68b8000,0xb6908000)]

Other Threads:
  0xb676d800 VMThread [stack: 0xae134000,0xae1b4000] [id=4904]
  0xb679a800 WatcherThread [stack: 0xad9ce000,0xada4e000] [id=4910]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap:
 def new generation  total 1920K, used 720K [0xae600000, 0xae800000, 0xb0600000)
  eden space 1792K,  33% used [0xae600000, 0xae694350, 0xae7c0000)
  from space 128K, 100% used [0xae7c0000, 0xae7e0000, 0xae7e0000)
  to  space 128K,  0% used [0xae7e0000, 0xae7e0000, 0xae800000)
 tenured generation  total 4096K, used 1212K [0xb0600000, 0xb0a00000, 0xb4600000)
  the space 4096K,  29% used [0xb0600000, 0xb072f360, 0xb072f400, 0xb0a00000)
 Metaspace      used 2705K, capacity 2784K, committed 2840K, reserved 4400K

Card table byte_map: [0xb6829000,0xb685a000] byte_map_base: 0xb62b6000

Polling page: 0xb6f0d000

CodeCache: size=32768Kb used=749Kb max_used=749Kb free=32018Kb
 bounds [0xb4700000, 0xb47c0000, 0xb6700000]
 total_blobs=330 nmethods=103 adapters=156
 compilation: enabled

Compilation events (10 events):
Event: 9.761 Thread 0xb6796800  99            java.lang.StringBuilder::toString (17 bytes)
Event: 9.762 Thread 0xb6796800 nmethod 99 0xb47ba548 code [0xb47ba640, 0xb47ba744]
Event: 9.967 Thread 0xb6796800  100            java.util.ArrayList$Itr::next (66 bytes)
Event: 9.969 Thread 0xb6796800 nmethod 100 0xb47ba7c8 code [0xb47ba8f0, 0xb47baafc]
Event: 9.969 Thread 0xb6796800  101            java.util.ArrayList$Itr::checkForComodification (23 bytes)
Event: 9.970 Thread 0xb6796800 nmethod 101 0xb47bacc8 code [0xb47badc0, 0xb47baeb4]
Event: 10.038 Thread 0xb6796800  102            java.lang.AbstractStringBuilder::expandCapacity (50 bytes)
Event: 10.040 Thread 0xb6796800 nmethod 102 0xb47baf88 code [0xb47bb090, 0xb47bb2c0]
Event: 10.389 Thread 0xb6796800  103            java.util.ArrayList::size (5 bytes)
Event: 10.390 Thread 0xb6796800 nmethod 103 0xb47bb3c8 code [0xb47bb4b0, 0xb47bb538]

GC Heap History (4 events):
Event: 2.208 GC heap before
{Heap before GC invocations=0 (full 0):
 def new generation  total 1920K, used 1753K [0xae600000, 0xae800000, 0xb0600000)
  eden space 1792K,  97% used [0xae600000, 0xae7b66c0, 0xae7c0000)
  from space 128K,  0% used [0xae7c0000, 0xae7c0000, 0xae7e0000)
  to  space 128K,  0% used [0xae7e0000, 0xae7e0000, 0xae800000)
 tenured generation  total 4096K, used 0K [0xb0600000, 0xb0a00000, 0xb4600000)
  the space 4096K,  0% used [0xb0600000, 0xb0600000, 0xb0600200, 0xb0a00000)
 Metaspace      used 2203K, capacity 2336K, committed 2456K, reserved 4400K
Event: 2.224 GC heap after
Heap after GC invocations=1 (full 0):
 def new generation  total 1920K, used 128K [0xae600000, 0xae800000, 0xb0600000)
  eden space 1792K,  0% used [0xae600000, 0xae600000, 0xae7c0000)
  from space 128K, 100% used [0xae7e0000, 0xae800000, 0xae800000)
  to  space 128K,  0% used [0xae7c0000, 0xae7c0000, 0xae7e0000)
 tenured generation  total 4096K, used 688K [0xb0600000, 0xb0a00000, 0xb4600000)
  the space 4096K,  16% used [0xb0600000, 0xb06ac310, 0xb06ac400, 0xb0a00000)
 Metaspace      used 2203K, capacity 2336K, committed 2456K, reserved 4400K
}
Event: 7.276 GC heap before
{Heap before GC invocations=1 (full 0):
 def new generation  total 1920K, used 1920K [0xae600000, 0xae800000, 0xb0600000)
  eden space 1792K, 100% used [0xae600000, 0xae7c0000, 0xae7c0000)
  from space 128K, 100% used [0xae7e0000, 0xae800000, 0xae800000)
  to  space 128K,  0% used [0xae7c0000, 0xae7c0000, 0xae7e0000)
 tenured generation  total 4096K, used 688K [0xb0600000, 0xb0a00000, 0xb4600000)
  the space 4096K,  16% used [0xb0600000, 0xb06ac310, 0xb06ac400, 0xb0a00000)
 Metaspace      used 2691K, capacity 2784K, committed 2840K, reserved 4400K
Event: 7.291 GC heap after
Heap after GC invocations=2 (full 0):
 def new generation  total 1920K, used 128K [0xae600000, 0xae800000, 0xb0600000)
  eden space 1792K,  0% used [0xae600000, 0xae600000, 0xae7c0000)
  from space 128K, 100% used [0xae7c0000, 0xae7e0000, 0xae7e0000)
  to  space 128K,  0% used [0xae7e0000, 0xae7e0000, 0xae800000)
 tenured generation  total 4096K, used 1212K [0xb0600000, 0xb0a00000, 0xb4600000)
  the space 4096K,  29% used [0xb0600000, 0xb072f360, 0xb072f400, 0xb0a00000)
 Metaspace      used 2691K, capacity 2784K, committed 2840K, reserved 4400K
}

Deoptimization events (0 events):
No events

Internal exceptions (10 events):
Event: 10.943 Thread 0xb6705800 Exception <a 'com/ni/vision/VisionException': IMAQdxError: -1074360316: Invalid camera session> (0xae669230) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jni.cpp, line 742]
Event: 11.012 Thread 0xb6705800 Exception <a 'com/ni/vision/VisionException': IMAQdxError: -1074360316: Invalid camera session> (0xae66a400) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jni.cpp, line 742]
Event: 11.081 Thread 0xb6705800 Exception <a 'com/ni/vision/VisionException': IMAQdxError: -1074360316: Invalid camera session> (0xae66b5d0) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jni.cpp, line 742]
Event: 11.151 Thread 0xb6705800 Exception <a 'com/ni/vision/VisionException': IMAQdxError: -1074360316: Invalid camera session> (0xae66c7a0) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jni.cpp, line 742]
Event: 11.160 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae66dc30) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]
Event: 11.162 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae672d08) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]
Event: 11.164 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae675850) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]
Event: 11.166 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae677708) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]
Event: 11.169 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae679c20) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]
Event: 11.191 Thread 0xb6705800 Exception <a 'java/security/PrivilegedActionException'> (0xae68a458) thrown at [/HUDSON/workspace/8-2-build-elinux-arm-vfp-sflt/jdk8u6/612/hotspot/src/share/vm/prims/jvm.cpp, line 1248]

Events (10 events):
Event: 11.161 loading class jaci/pathfinder/Pathfinder
Event: 11.161 loading class jaci/pathfinder/Pathfinder done
Event: 11.164 loading class jaci/pathfinder/Trajectory$Config
Event: 11.164 loading class jaci/pathfinder/Trajectory$Config done
Event: 11.166 loading class jaci/pathfinder/Trajectory$FitMethod
Event: 11.166 loading class jaci/pathfinder/Trajectory$FitMethod done
Event: 11.168 loading class jaci/pathfinder/PathfinderJNI
Event: 11.168 loading class jaci/pathfinder/PathfinderJNI done
Event: 11.191 loading class jaci/pathfinder/Trajectory
Event: 11.191 loading class jaci/pathfinder/Trajectory done


Dynamic libraries:
00008000-00009000 r-xp 00000000 00:0d 6054      /usr/local/frc/JRE/bin/java
00010000-00011000 rwxp 00000000 00:0d 6054      /usr/local/frc/JRE/bin/java
00011000-00035000 rwxp 00000000 00:00 0          [heap]
ab700000-ab720000 rwxp 00000000 00:00 0
ab720000-ab800000 ---p 00000000 00:00 0
ab802000-ab822000 rwxs 00200000 00:05 8214      /dev/ni/NiRioSrv:fpga:00000000\nirio_transport\0
ab950000-aba0e000 r-xp 00000000 00:0d 2846      /usr/local/frc/rpath-lib/libstdc++.so.6.0.20
aba0e000-aba15000 ---p 000be000 00:0d 2846      /usr/local/frc/rpath-lib/libstdc++.so.6.0.20
aba15000-aba19000 r-xp 000bd000 00:0d 2846      /usr/local/frc/rpath-lib/libstdc++.so.6.0.20
aba19000-aba1a000 rwxp 000c1000 00:0d 2846      /usr/local/frc/rpath-lib/libstdc++.so.6.0.20
aba1a000-aba21000 rwxp 00000000 00:00 0
aba21000-aba28000 r-xp 00000000 00:10 18981      /var/volatile/tmp/pathfinderJNI4167093640070579939.so
aba28000-aba2f000 ---p 00007000 00:10 18981      /var/volatile/tmp/pathfinderJNI4167093640070579939.so
aba2f000-aba30000 rwxp 00006000 00:10 18981      /var/volatile/tmp/pathfinderJNI4167093640070579939.so
aba30000-aba33000 ---p 00000000 00:00 0
aba33000-aba80000 rwxp 00000000 00:00 0          [stack:4928]
aba80000-aba83000 ---p 00000000 00:00 0
aba83000-abac0000 rwxp 00000000 00:00 0          [stack:4927]
abac0000-abac1000 ---p 00000000 00:00 0
abac1000-abb56000 rwxp 00000000 00:00 0          [stack:4926]
abb56000-abc00000 ---p 00000000 00:00 0
abc01000-abc02000 ---p 00000000 00:00 0
abc02000-abc41000 rwxp 00000000 00:00 0          [stack:4925]
abc41000-abc42000 ---p 00000000 00:00 0
abc42000-abc81000 rwxp 00000000 00:00 0          [stack:4924]
abc81000-abc82000 ---p 00000000 00:00 0
abc82000-abcc1000 rwxp 00000000 00:00 0          [stack:4923]
abcc1000-abcc2000 ---p 00000000 00:00 0
abcc2000-abd01000 rwxp 00000000 00:00 0          [stack:4922]
abd01000-abd84000 r-xp 00000000 00:10 18978      /var/volatile/tmp/libNetworkTablesJNI8680679539277384756.so
abd84000-abd94000 ---p 00083000 00:10 18978      /var/volatile/tmp/libNetworkTablesJNI8680679539277384756.so
abd94000-abd96000 rwxp 00083000 00:10 18978      /var/volatile/tmp/libNetworkTablesJNI8680679539277384756.so
abd96000-abd99000 ---p 00000000 00:00 0
abd99000-abde6000 rwxp 00000000 00:00 0          [stack:4921]
abde6000-abde7000 ---p 00000000 00:00 0
abde7000-abe26000 rwxp 00000000 00:00 0          [stack:4920]
abe26000-abe27000 ---p 00000000 00:00 0
abe27000-abe66000 rwxp 00000000 00:00 0          [stack:4919]
abe66000-abe67000 ---p 00000000 00:00 0
abe67000-abea6000 rwxp 00000000 00:00 0          [stack:4917]
abea6000-abee6000 rwxs 00000000 00:04 0          /SYSV020d0db8 (deleted)
abee6000-abee7000 ---p 00000000 00:00 0
abee7000-abf26000 rwxp 00000000 00:00 0          [stack:4916]
abf26000-abf27000 ---p 00000000 00:00 0
abf27000-abf66000 rwxp 00000000 00:00 0          [stack:4915]
abf66000-abf67000 ---p 00000000 00:00 0
abf67000-abfa6000 rwxp 00000000 00:00 0          [stack:4914]
abfa6000-abfa7000 ---p 00000000 00:00 0
abfa7000-abfe6000 rwxp 00000000 00:00 0          [stack:4913]
abfe6000-abfe7000 ---p 00000000 00:00 0
abfe7000-ac026000 rwxp 00000000 00:00 0          [stack:4912]
ac026000-ac027000 ---p 00000000 00:00 0
ac027000-ac0c1000 rwxp 00000000 00:00 0          [stack:4911]
ac0c1000-ac0f7000 r-xp 00000000 00:0d 2925      /usr/local/natinst/lib/libniu3v.so.1.5.0
ac0f7000-ac0ff000 ---p 00036000 00:0d 2925      /usr/local/natinst/lib/libniu3v.so.1.5.0
ac0ff000-ac100000 rwxp 00036000 00:0d 2925      /usr/local/natinst/lib/libniu3v.so.1.5.0
ac100000-ac131000 rwxp 00000000 00:00 0
ac131000-ac134000 rwxp 00000000 00:00 0
ac134000-ac200000 rwxp 00000000 00:00 0
ac204000-ac20a000 r-xp 00000000 00:0d 2977      /usr/local/natinst/lib/libnimdnsResponder.so.215.0.0
ac20a000-ac211000 ---p 00006000 00:0d 2977      /usr/local/natinst/lib/libnimdnsResponder.so.215.0.0
ac211000-ac212000 rwxp 00005000 00:0d 2977      /usr/local/natinst/lib/libnimdnsResponder.so.215.0.0
ac212000-ac214000 r-xp 00000000 00:0d 2378      /usr/lib/gconv/ISO8859-1.so
ac214000-ac21b000 ---p 00002000 00:0d 2378      /usr/lib/gconv/ISO8859-1.so
ac21b000-ac21c000 r-xp 00001000 00:0d 2378      /usr/lib/gconv/ISO8859-1.so
ac21c000-ac21d000 rwxp 00002000 00:0d 2378      /usr/lib/gconv/ISO8859-1.so
ac21d000-ac21e000 rwxp 00000000 00:00 0
ac21e000-ac26f000 rwxp 00000000 00:00 0
ac26f000-ac270000 rwxp 00000000 00:00 0
ac270000-ac279000 rwxs 00000000 00:0d 17705      /var/lib/natinst/nipal/tmp/NISSPALSharedDataSegment
ac279000-ac304000 r-xp 00000000 00:0d 3135      /usr/local/natinst/nipal/lib/libnipalu.so.15.0.0
ac304000-ac30b000 ---p 0008b000 00:0d 3135      /usr/local/natinst/nipal/lib/libnipalu.so.15.0.0
ac30b000-ac30f000 rwxp 0008a000 00:0d 3135      /usr/local/natinst/nipal/lib/libnipalu.so.15.0.0
ac30f000-ac317000 rwxp 00000000 00:00 0
ac317000-ac354000 r-xp 00000000 00:0d 1806      /opt/GenICam_v2_3/bin/Linux_armv7-a/liblog4cpp_gcc-4.4-arm_v2_3.so
ac354000-ac35b000 ---p 0003d000 00:0d 1806      /opt/GenICam_v2_3/bin/Linux_armv7-a/liblog4cpp_gcc-4.4-arm_v2_3.so
ac35b000-ac35d000 rwxp 0003c000 00:0d 1806      /opt/GenICam_v2_3/bin/Linux_armv7-a/liblog4cpp_gcc-4.4-arm_v2_3.so
ac35d000-ac366000 r-xp 00000000 00:0d 1804      /opt/GenICam_v2_3/bin/Linux_armv7-a/libMathParser_gcc-4.4-arm_v2_3.so
ac366000-ac36d000 ---p 00009000 00:0d 1804      /opt/GenICam_v2_3/bin/Linux_armv7-a/libMathParser_gcc-4.4-arm_v2_3.so
ac36d000-ac36e000 rwxp 00008000 00:0d 1804      /opt/GenICam_v2_3/bin/Linux_armv7-a/libMathParser_gcc-4.4-arm_v2_3.so
ac36e000-ac36f000 rwxp 00000000 00:00 0
ac36f000-ac62d000 r-xp 00000000 00:0d 2982      /usr/local/natinst/lib/libnivissvc.so.15.0.0
ac62d000-ac635000 ---p 002be000 00:0d 2982      /usr/local/natinst/lib/libnivissvc.so.15.0.0
ac635000-ac641000 rwxp 002be000 00:0d 2982      /usr/local/natinst/lib/libnivissvc.so.15.0.0
ac641000-ac651000 rwxp 00000000 00:00 0
ac651000-ac653000 r-xp 00000000 00:0d 2928      /usr/local/natinst/lib/libni_rtlog.so.2.4.0
ac653000-ac65b000 ---p 00002000 00:0d 2928      /usr/local/natinst/lib/libni_rtlog.so.2.4.0
ac65b000-ac65c000 rwxp 00002000 00:0d 2928      /usr/local/natinst/lib/libni_rtlog.so.2.4.0
ac65c000-ad093000 r-xp 00000000 00:0d 2976      /usr/local/natinst/lib/libnivision.so.15.0.0
ad093000-ad09b000 ---p 00a37000 00:0d 2976      /usr/local/natinst/lib/libnivision.so.15.0.0
ad09b000-ad0ab000 rwxp 00a37000 00:0d 2976      /usr/local/natinst/lib/libnivision.so.15.0.0
ad0ab000-ad0ac000 rwxp 00000000 00:00 0
ad0ac000-ad265000 r-xp 00000000 00:0d 2941      /usr/local/natinst/lib/libniimaqdx.so.15.0.0
ad265000-ad26c000 ---p 001b9000 00:0d 2941      /usr/local/natinst/lib/libniimaqdx.so.15.0.0
ad26c000-ad27a000 rwxp 001b8000 00:0d 2941      /usr/local/natinst/lib/libniimaqdx.so.15.0.0
ad27a000-ad352000 rwxp 00000000 00:00 0
ad352000-ad586000 r-xp 00000000 00:0d 1805      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGenApi_gcc-4.4-arm_v2_3.so
ad586000-ad58e000 ---p 00234000 00:0d 1805      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGenApi_gcc-4.4-arm_v2_3.so
ad58e000-ad60e000 rwxp 00234000 00:0d 1805      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGenApi_gcc-4.4-arm_v2_3.so
ad60e000-ad60f000 rwxp 00000000 00:00 0
ad60f000-ad66b000 r-xp 00000000 00:0d 2826      /usr/local/frc/lib/libRoboRIO_FRC_ChipObject.so.16.0.0
ad66b000-ad672000 ---p 0005c000 00:0d 2826      /usr/local/frc/lib/libRoboRIO_FRC_ChipObject.so.16.0.0
ad672000-ad675000 rwxp 0005b000 00:0d 2826      /usr/local/frc/lib/libRoboRIO_FRC_ChipObject.so.16.0.0
ad675000-ad6e9000 r-xp 00000000 00:0d 2970      /usr/local/natinst/lib/libNiFpga.so.15.0.0
ad6e9000-ad6f0000 ---p 00074000 00:0d 2970      /usr/local/natinst/lib/libNiFpga.so.15.0.0
ad6f0000-ad6f4000 rwxp 00073000 00:0d 2970      /usr/local/natinst/lib/libNiFpga.so.15.0.0
ad6f4000-ad707000 r-xp 00000000 00:0d 1792      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGCBase_gcc-4.4-arm_v2_3.so
ad707000-ad70f000 ---p 00013000 00:0d 1792      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGCBase_gcc-4.4-arm_v2_3.so
ad70f000-ad710000 rwxp 00013000 00:0d 1792      /opt/GenICam_v2_3/bin/Linux_armv7-a/libGCBase_gcc-4.4-arm_v2_3.so
ad710000-ad722000 r-xp 00000000 00:0d 2952      /usr/local/natinst/lib/libNiFpgaLv.so.15.0.0
ad722000-ad72a000 ---p 00012000 00:0d 2952      /usr/local/natinst/lib/libNiFpgaLv.so.15.0.0
ad72a000-ad72b000 rwxp 00012000 00:0d 2952      /usr/local/natinst/lib/libNiFpgaLv.so.15.0.0
ad72b000-ad75a000 r-xp 00000000 00:0d 3512      /usr/local/vxipnp/linux/lib/libvisa.so
ad75a000-ad762000 ---p 0002f000 00:0d 3512      /usr/local/vxipnp/linux/lib/libvisa.so
ad762000-ad763000 rwxp 0002f000 00:0d 3512      /usr/local/vxipnp/linux/lib/libvisa.so
ad763000-ad773000 rwxp 00000000 00:00 0
ad773000-ad797000 r-xp 00000000 00:0d 3020      /usr/local/natinst/lib/libni_emb.so.8.0.0
ad797000-ad79f000 ---p 00024000 00:0d 3020      /usr/local/natinst/lib/libni_emb.so.8.0.0
ad79f000-ad7a0000 rwxp 00024000 00:0d 3020      /usr/local/natinst/lib/libni_emb.so.8.0.0
ad7a0000-ad814000 r-xp 00000000 00:0d 2827      /usr/local/frc/lib/libFRC_NetworkCommunication.so.16.0.0
ad814000-ad81c000 ---p 00074000 00:0d 2827      /usr/local/frc/lib/libFRC_NetworkCommunication.so.16.0.0
ad81c000-ad81f000 rwxp 00074000 00:0d 2827      /usr/local/frc/lib/libFRC_NetworkCommunication.so.16.0.0
ad81f000-ad90a000 r-xp 00000000 00:0d 2953      /usr/local/natinst/lib/libNiRioSrv.so.15.0.0
ad90a000-ad911000 ---p 000eb000 00:0d 2953      /usr/local/natinst/lib/libNiRioSrv.so.15.0.0
ad911000-ad917000 rwxp 000ea000 00:0d 2953      /usr/local/natinst/lib/libNiRioSrv.so.15.0.0
ad917000-ad9bc000 r-xp 00000000 00:10 18968      /var/volatile/tmp/libwpilibJavaJNI693166527143768421.so
ad9bc000-ad9cb000 ---p 000a5000 00:10 18968      /var/volatile/tmp/libwpilibJavaJNI693166527143768421.so
ad9cb000-ad9cd000 rwxp 000a4000 00:10 18968      /var/volatile/tmp/libwpilibJavaJNI693166527143768421.so
ad9cd000-ad9ce000 rwxp 00000000 00:00 0
ad9ce000-ad9cf000 ---p 00000000 00:00 0
ad9cf000-ada4e000 rwxp 00000000 00:00 0          [stack:4910]
ada4e000-ada51000 ---p 00000000 00:00 0
ada51000-ada9e000 rwxp 00000000 00:00 0          [stack:4909]
ada9e000-adaa1000 ---p 00000000 00:00 0
adaa1000-adb1e000 rwxp 00000000 00:00 0          [stack:4908]
adb1e000-adb21000 ---p 00000000 00:00 0
adb21000-adb6e000 rwxp 00000000 00:00 0          [stack:4907]
adb6e000-adc2d000 r-xp 00000000 00:0d 2853      /usr/local/frc/rpath-lib/libstdc++.so.6
adc2d000-adc3c000 ---p 000bf000 00:0d 2853      /usr/local/frc/rpath-lib/libstdc++.so.6
adc3c000-adc40000 r-xp 000be000 00:0d 2853      /usr/local/frc/rpath-lib/libstdc++.so.6
adc40000-adc41000 rwxp 000c2000 00:0d 2853      /usr/local/frc/rpath-lib/libstdc++.so.6
adc41000-adc48000 rwxp 00000000 00:00 0
adc48000-addd8000 r-xp 00000000 00:0d 1345      /lib/libnss_niauth.so.15.0.0
addd8000-adddf000 ---p 00190000 00:0d 1345      /lib/libnss_niauth.so.15.0.0
adddf000-addfd000 rwxp 0018f000 00:0d 1345      /lib/libnss_niauth.so.15.0.0
addfd000-ade21000 rwxp 00000000 00:00 0
ade21000-adf00000 ---p 00000000 00:00 0
adf03000-adf08000 r-xp 00000000 00:0d 1808      /opt/GenICam_v2_3/bin/Linux_armv7-a/libLog_gcc-4.4-arm_v2_3.so
adf08000-adf0f000 ---p 00005000 00:0d 1808      /opt/GenICam_v2_3/bin/Linux_armv7-a/libLog_gcc-4.4-arm_v2_3.so
adf0f000-adf10000 rwxp 00004000 00:0d 1808      /opt/GenICam_v2_3/bin/Linux_armv7-a/libLog_gcc-4.4-arm_v2_3.so
adf10000-adf21000 r-xp 00000000 00:0d 2948      /usr/local/natinst/lib/libnirio_emb_can.so.15.0.0
adf21000-adf28000 ---p 00011000 00:0d 2948      /usr/local/natinst/lib/libnirio_emb_can.so.15.0.0
adf28000-adf29000 rwxp 00010000 00:0d 2948      /usr/local/natinst/lib/libnirio_emb_can.so.15.0.0
adf29000-adf60000 r-xp 00000000 00:0d 2350      /usr/lib/locale/L1/LC_CTYPE
adf60000-adf63000 ---p 00000000 00:00 0
adf63000-adfb0000 rwxp 00000000 00:00 0          [stack:4906]
adfb0000-adfb3000 ---p 00000000 00:00 0
adfb3000-ae068000 rwxp 00000000 00:00 0          [stack:4905]
ae068000-ae100000 ---p 00000000 00:00 0
ae106000-ae107000 r-xp 00000000 00:0d 2834      /usr/local/frc/lib/libspi.so.1.0.0
ae107000-ae10e000 ---p 00001000 00:0d 2834      /usr/local/frc/lib/libspi.so.1.0.0
ae10e000-ae10f000 rwxp 00000000 00:0d 2834      /usr/local/frc/lib/libspi.so.1.0.0
ae10f000-ae110000 r-xp 00000000 00:0d 2836      /usr/local/frc/lib/libi2c.so.1.0.0
ae110000-ae117000 ---p 00001000 00:0d 2836      /usr/local/frc/lib/libi2c.so.1.0.0
ae117000-ae118000 rwxp 00000000 00:0d 2836      /usr/local/frc/lib/libi2c.so.1.0.0
ae118000-ae129000 r-xp 00000000 00:0d 1409      /lib/libnsl-2.20.so
ae129000-ae130000 ---p 00011000 00:0d 1409      /lib/libnsl-2.20.so
ae130000-ae131000 r-xp 00010000 00:0d 1409      /lib/libnsl-2.20.so
ae131000-ae132000 rwxp 00011000 00:0d 1409      /lib/libnsl-2.20.so
ae132000-ae134000 rwxp 00000000 00:00 0
ae134000-ae135000 ---p 00000000 00:00 0
ae135000-ae47a000 rwxp 00000000 00:00 0          [stack:4904]
ae47a000-ae600000 ---p 00000000 00:00 0
ae600000-ae800000 rwxp 00000000 00:00 0
ae800000-b0600000 ---p 00000000 00:00 0
b0600000-b0a00000 rwxp 00000000 00:00 0
b0a00000-b4600000 ---p 00000000 00:00 0
b4603000-b4604000 r-xp 00000000 00:0d 2825      /usr/local/frc/lib/libFRC_NetworkCommunicationLV.so.16.0.0
b4604000-b460b000 ---p 00001000 00:0d 2825      /usr/local/frc/lib/libFRC_NetworkCommunicationLV.so.16.0.0
b460b000-b460c000 rwxp 00000000 00:0d 2825      /usr/local/frc/lib/libFRC_NetworkCommunicationLV.so.16.0.0
b460c000-b4612000 r-xp 00000000 00:0d 1393      /lib/libnss_compat-2.20.so
b4612000-b4619000 ---p 00006000 00:0d 1393      /lib/libnss_compat-2.20.so
b4619000-b461a000 r-xp 00005000 00:0d 1393      /lib/libnss_compat-2.20.so
b461a000-b461b000 rwxp 00006000 00:0d 1393      /lib/libnss_compat-2.20.so
b4620000-b4625000 r-xp 00000000 00:0d 2344      /usr/lib/locale/L1/LC_COLLATE
b4625000-b4683000 rwxp 00000000 00:00 0
b4683000-b4700000 ---p 00000000 00:00 0
b4700000-b47c0000 rwxp 00000000 00:00 0
b47c0000-b6700000 ---p 00000000 00:00 0
b6700000-b67f6000 rwxp 00000000 00:00 0
b67f6000-b6800000 ---p 00000000 00:00 0
b6800000-b6801000 rwxp 00000000 00:00 0
b6801000-b6802000 rwxs 00000000 00:05 9392      /dev/shm/IMAQdxInterfaceFilesActivityCounter
b6802000-b6803000 r-xp 00000000 00:0d 2355      /usr/lib/locale/L1/LC_NUMERIC
b6803000-b6804000 r-xp 00000000 00:0d 2348      /usr/lib/locale/L1/LC_TIME
b6804000-b6805000 r-xp 00000000 00:0d 2353      /usr/lib/locale/L1/LC_MONETARY
b6805000-b6806000 r-xp 00000000 00:0d 2346      /usr/lib/locale/L1/LC_MESSAGES/SYS_LC_MESSAGES
b6806000-b6807000 r-xp 00000000 00:0d 2351      /usr/lib/locale/L1/LC_PAPER
b6807000-b6808000 r-xp 00000000 00:0d 2347      /usr/lib/locale/L1/LC_NAME
b6808000-b680b000 rwxp 00000000 00:00 0
b680b000-b6829000 ---p 00000000 00:00 0
b6829000-b682a000 rwxp 00000000 00:00 0
b682a000-b6839000 ---p 00000000 00:00 0
b6839000-b683b000 rwxp 00000000 00:00 0
b683b000-b6859000 ---p 00000000 00:00 0
b6859000-b685a000 rwxp 00000000 00:00 0
b685a000-b686c000 r-xp 00000000 00:0d 6078      /usr/local/frc/JRE/lib/arm/libzip.so
b686c000-b6873000 ---p 00012000 00:0d 6078      /usr/local/frc/JRE/lib/arm/libzip.so
b6873000-b6874000 rwxp 00011000 00:0d 6078      /usr/local/frc/JRE/lib/arm/libzip.so
b6874000-b6890000 r-xp 00000000 00:0d 6070      /usr/local/frc/JRE/lib/arm/libjava.so
b6890000-b6898000 ---p 0001c000 00:0d 6070      /usr/local/frc/JRE/lib/arm/libjava.so
b6898000-b6899000 rwxp 0001c000 00:0d 6070      /usr/local/frc/JRE/lib/arm/libjava.so
b6899000-b68a0000 r-xp 00000000 00:0d 6077      /usr/local/frc/JRE/lib/arm/libverify.so
b68a0000-b68a8000 ---p 00007000 00:0d 6077      /usr/local/frc/JRE/lib/arm/libverify.so
b68a8000-b68a9000 rwxp 00007000 00:0d 6077      /usr/local/frc/JRE/lib/arm/libverify.so
b68a9000-b68af000 r-xp 00000000 00:0d 1394      /lib/librt-2.20.so
b68af000-b68b6000 ---p 00006000 00:0d 1394      /lib/librt-2.20.so
b68b6000-b68b7000 r-xp 00005000 00:0d 1394      /lib/librt-2.20.so
b68b7000-b68b8000 rwxp 00006000 00:0d 1394      /lib/librt-2.20.so
b68b8000-b68bb000 ---p 00000000 00:00 0
b68bb000-b6908000 rwxp 00000000 00:00 0          [stack:4903]
b6908000-b6972000 r-xp 00000000 00:0d 1429      /lib/libm-2.20.so
b6972000-b6979000 ---p 0006a000 00:0d 1429      /lib/libm-2.20.so
b6979000-b697a000 r-xp 00069000 00:0d 1429      /lib/libm-2.20.so
b697a000-b697b000 rwxp 0006a000 00:0d 1429      /lib/libm-2.20.so
b697b000-b6d01000 r-xp 00000000 00:0d 6063      /usr/local/frc/JRE/lib/arm/client/libjvm.so
b6d01000-b6d09000 ---p 00386000 00:0d 6063      /usr/local/frc/JRE/lib/arm/client/libjvm.so
b6d09000-b6d33000 rwxp 00386000 00:0d 6063      /usr/local/frc/JRE/lib/arm/client/libjvm.so
b6d33000-b6d55000 rwxp 00000000 00:00 0
b6d55000-b6d72000 r-xp 00000000 00:0d 1402      /lib/libgcc_s.so.1
b6d72000-b6d79000 ---p 0001d000 00:0d 1402      /lib/libgcc_s.so.1
b6d79000-b6d7a000 rwxp 0001c000 00:0d 1402      /lib/libgcc_s.so.1
b6d7a000-b6e9f000 r-xp 00000000 00:0d 1785      /lib/libc-2.20.so
b6e9f000-b6ea7000 ---p 00125000 00:0d 1785      /lib/libc-2.20.so
b6ea7000-b6ea9000 r-xp 00125000 00:0d 1785      /lib/libc-2.20.so
b6ea9000-b6eaa000 rwxp 00127000 00:0d 1785      /lib/libc-2.20.so
b6eaa000-b6ead000 rwxp 00000000 00:00 0
b6ead000-b6eaf000 r-xp 00000000 00:0d 1403      /lib/libdl-2.20.so
b6eaf000-b6eb6000 ---p 00002000 00:0d 1403      /lib/libdl-2.20.so
b6eb6000-b6eb7000 r-xp 00001000 00:0d 1403      /lib/libdl-2.20.so
b6eb7000-b6eb8000 rwxp 00002000 00:0d 1403      /lib/libdl-2.20.so
b6eb8000-b6ec8000 r-xp 00000000 00:0d 6066      /usr/local/frc/JRE/lib/arm/jli/libjli.so
b6ec8000-b6ec9000 rwxp 00010000 00:0d 6066      /usr/local/frc/JRE/lib/arm/jli/libjli.so
b6ec9000-b6ede000 r-xp 00000000 00:0d 1354      /lib/libpthread-2.20.so
b6ede000-b6ee5000 ---p 00015000 00:0d 1354      /lib/libpthread-2.20.so
b6ee5000-b6ee6000 r-xp 00014000 00:0d 1354      /lib/libpthread-2.20.so
b6ee6000-b6ee7000 rwxp 00015000 00:0d 1354      /lib/libpthread-2.20.so
b6ee7000-b6ee9000 rwxp 00000000 00:00 0
b6ee9000-b6f08000 r-xp 00000000 00:0d 1353      /lib/ld-2.20.so
b6f08000-b6f09000 rwxp 00000000 00:00 0
b6f09000-b6f0a000 r-xp 00000000 00:0d 2349      /usr/lib/locale/L1/LC_ADDRESS
b6f0a000-b6f0b000 r-xp 00000000 00:0d 2352      /usr/lib/locale/L1/LC_TELEPHONE
b6f0b000-b6f0c000 r-xp 00000000 00:0d 2354      /usr/lib/locale/L1/LC_MEASUREMENT
b6f0c000-b6f0d000 r-xp 00000000 00:0d 2343      /usr/lib/locale/L1/LC_IDENTIFICATION
b6f0d000-b6f0e000 r-xp 00000000 00:00 0
b6f0e000-b6f0f000 rwxp 00000000 00:00 0
b6f0f000-b6f10000 r-xp 00000000 00:00 0          [sigpage]
b6f10000-b6f11000 r-xp 0001f000 00:0d 1353      /lib/ld-2.20.so
b6f11000-b6f12000 rwxp 00020000 00:0d 1353      /lib/ld-2.20.so
be8db000-be8fc000 rw-p 00000000 00:00 0          [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]

VM Arguments:
java_command: /home/lvuser/FRCUserProgram.jar
java_class_path (initial): /home/lvuser/FRCUserProgram.jar
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/frc/bin:/usr/local/natinst/bin
LD_LIBRARY_PATH=/usr/local/frc/rpath-lib/

Signal Handlers:
SIGSEGV: [libjvm.so+0x318cad], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x318cad], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x277a09], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libnivision.so.13+0x94a9f8], sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGXFSZ: [libjvm.so+0x277a09], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x277a09], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x277abd], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x277d8d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x277d8d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x277d8d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x277d8d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Linux
uname:Linux 3.14.40-rt37-ni-3.2.0d0 #1 SMP PREEMPT RT Mon Oct 26 13:32:00 CDT 2015 armv7l
libc:glibc 2.20 NPTL 2.20
rlimit: STACK 256k, CORE 2048k, NPROC 1965, NOFILE 4096, AS infinity
load average:3.10 2.78 2.55

/proc/meminfo:
MemTotal:        251972 kB
MemFree:          88984 kB
MemAvailable:    142232 kB
Buffers:              0 kB
Cached:            89980 kB
SwapCached:            0 kB
Active:            79016 kB
Inactive:          24960 kB
Active(anon):      50324 kB
Inactive(anon):      396 kB
Active(file):      28692 kB
Inactive(file):    24564 kB
Unevictable:      29064 kB
Mlocked:          29064 kB
HighTotal:            0 kB
HighFree:              0 kB
LowTotal:        251972 kB
LowFree:          88984 kB
SwapTotal:            0 kB
SwapFree:              0 kB
Dirty:                0 kB
Writeback:            0 kB
AnonPages:        43080 kB
Mapped:            49016 kB
Shmem:            15264 kB
Slab:              17096 kB
SReclaimable:      7888 kB
SUnreclaim:        9208 kB
KernelStack:        2288 kB
PageTables:        1460 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      216692 kB
Committed_AS:    141064 kB
VmallocTotal:    761856 kB
VmallocUsed:      20416 kB
VmallocChunk:    633612 kB


CPU:total 2 (ARMv7), vfp

/proc/cpuinfo:
processor      : 0
model name      : ARMv7 Processor rev 0 (v7l)
BogoMIPS        : 1325.46
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant    : 0x3
CPU part        : 0xc09
CPU revision    : 0

processor      : 1
model name      : ARMv7 Processor rev 0 (v7l)
BogoMIPS        : 1332.01
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant    : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : Xilinx Zynq Platform
Revision        : 0000
Serial          : 0000000000000000


Memory: 4k page, physical 251972k(88984k free), swap 0k(0k free)

vm_info: Java HotSpot(TM) Embedded Client VM (25.6-b23) for linux-arm-vfp-sflt JRE (1.8.0_06-b23), built on Jun 12 2014 09:40:18 by "java_re" with gcc 4.7.2 20120731 (prerelease)

time: Tue Mar 29 18:30:50 2016
elapsed time: 11 seconds

The code sufficient to trigger this crash is pretty much exactly as described in the docs.
Code:

                Waypoint[] points = new Waypoint[] {
                            new Waypoint(-0.5, -0.5, Pathfinder.d2r(35)),      // Waypoint @ x=-4, y=-1, exit angle=-45 degrees
                            new Waypoint(-4.826, 0, Pathfinder.d2r(-90)),  // at start of outerworks, 190in
                            new Waypoint(-7.62, 0, Pathfinder.d2r(-90)),    // 300 in
                            new Waypoint(-4.826, 0, Pathfinder.d2r(-90)), // back out
                        };

                        Trajectory.Config config = new Trajectory.Config(Trajectory.FitMethod.HERMITE_CUBIC, Trajectory.Config.SAMPLES_HIGH, 0.001, 1.7, 2.0, 60.0);
                        Trajectory trajectory = Pathfinder.generate(points, config);
                        TankModifier modifier = new TankModifier(trajectory).modify(WHEELBASE_WIDTH);


Jaci 29-03-2016 22:34

Re: Pathfinder - I broke it
 
Quote:

Originally Posted by Aero (Post 1564890)
I'm having trouble running the creation code on the RoboRIO.

<snip>

The code sufficient to trigger this crash is pretty much exactly as described in the docs.
Code:

                Waypoint[] points = new Waypoint[] {
                            new Waypoint(-0.5, -0.5, Pathfinder.d2r(35)),      // Waypoint @ x=-4, y=-1, exit angle=-45 degrees
                            new Waypoint(-4.826, 0, Pathfinder.d2r(-90)),  // at start of outerworks, 190in
                            new Waypoint(-7.62, 0, Pathfinder.d2r(-90)),    // 300 in
                            new Waypoint(-4.826, 0, Pathfinder.d2r(-90)), // back out
                        };

                        Trajectory.Config config = new Trajectory.Config(Trajectory.FitMethod.HERMITE_CUBIC, Trajectory.Config.SAMPLES_HIGH, 0.001, 1.7, 2.0, 60.0);
                        Trajectory trajectory = Pathfinder.generate(points, config);
                        TankModifier modifier = new TankModifier(trajectory).modify(WHEELBASE_WIDTH);


The spline you're attempting to generate can't be generated. The angle of -90 degrees can't be fit if you're only moving in the X plane, as the angle of 0 is pointing towards X+

Ben Wolsieffer 29-03-2016 22:43

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I just tested and ran into the exact same problem:

Code:

➔ Launching «'/usr/local/frc/JRE/bin/java' '-jar' '/home/lvuser/FRCUserProgram.jar'»
platform: /Linux/arm/
********** Robot program starting **********
Platform: /Linux/arm/
NT: server: client CONNECTED: 10.20.84.6 port 54003
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xabd17110, pid=3163, tid=2880828512
#
# JRE version: Java(TM) SE Embedded Runtime Environment (8.0_06-b23) (build 1.8.0_06-b23)
# Java VM: Java HotSpot(TM) Embedded Client VM (25.6-b23 mixed mode linux-arm )
# Problematic frame:
# [thread -1413811104 also had an error]
C  [pathfinderJNI2908278789272954917.so+0x6110][thread -1413483424 also had an error]
[thread -1414466464 also had an error]  pf_trajectory_fromSecondOrderFilter+0x74[thread -1414794144 also had an error]


#
# Core dump written. Default location: //core or core.3163 (max size 2048 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid3163.log
#
# If you would like to submit a bug report, please visit:
#  http://bugreport.sun.com/bugreport/crash.jsp
#

The previous error only occurred once (the first time I loaded the code, oddly enough); after that I would get this error:
Code:

java.io.IOException: No space left on device
        at java.io.FileOutputStream.writeBytes(Native Method)
        at java.io.FileOutputStream.write(FileOutputStream.java:307)
        at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:40)
        at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:170)
        at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:182)

The temporary partition (/var/volatile/) is being filled for some reason, so that there is only around 2.4 to 2.6 MB free (it varies). This makes it so there isn't enough space to extract the WPILib HAL library. I assume this is caused by your library, as there is nothing in my code that writes to a file AFAIK. The problem goes away if I revert to the commit before I added in Pathfinder.

EDIT: Thinking about the problem more, my current hypothesis is that the core dumps and hs_err_pidxxxx.log files are being written to the temporary directory (the error message says they are being saved to "//", but I'm not sure what that means), and they are filling it up as the code restarts over and over. Eventually, this prevents WPILib from loading.

Ben Wolsieffer 29-03-2016 22:58

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I just saw your post, and I am probably running into the same problem. I'm a little confused as to how the coordinate system for Pathfinder works.

This is how I assumed it works, but I am probably misunderstanding it:
If the robot starts facing towards the direction I define as forward (ie. towards the opponent's castle):
Its initial heading is pi/2
A waypoint with x = 0, y > 0 and heading = pi/2 will cause the robot to drive straight forward.
A waypoint with x < 0, y = 0 and heading = pi will cause the robot to turn to the left and drive to the left, ending up facing left.
A waypoint with x < 0, y = 0 and heading = 0 will cause the generator to crash.
A waypoint with x = 0, y > 0 and heading = pi/4 will cause the robot to end in a position directly in front of where it started, but pointing to the right.

EDIT: I reread your post, and updated my examples.

Jaci 29-03-2016 23:19

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1565008)
I just tested and ran into the exact same problem:

Code:

➔ Launching «'/usr/local/frc/JRE/bin/java' '-jar' '/home/lvuser/FRCUserProgram.jar'»
platform: /Linux/arm/
********** Robot program starting **********
Platform: /Linux/arm/
NT: server: client CONNECTED: 10.20.84.6 port 54003
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xabd17110, pid=3163, tid=2880828512
#
# JRE version: Java(TM) SE Embedded Runtime Environment (8.0_06-b23) (build 1.8.0_06-b23)
# Java VM: Java HotSpot(TM) Embedded Client VM (25.6-b23 mixed mode linux-arm )
# Problematic frame:
# [thread -1413811104 also had an error]
C  [pathfinderJNI2908278789272954917.so+0x6110][thread -1413483424 also had an error]
[thread -1414466464 also had an error]  pf_trajectory_fromSecondOrderFilter+0x74[thread -1414794144 also had an error]


#
# Core dump written. Default location: //core or core.3163 (max size 2048 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid3163.log
#
# If you would like to submit a bug report, please visit:
#  http://bugreport.sun.com/bugreport/crash.jsp
#

The previous error only occurred once (the first time I loaded the code, oddly enough); after that I would get this error:
Code:

java.io.IOException: No space left on device
        at java.io.FileOutputStream.writeBytes(Native Method)
        at java.io.FileOutputStream.write(FileOutputStream.java:307)
        at edu.wpi.first.wpilibj.hal.JNIWrapper.<clinit>(JNIWrapper.java:40)
        at edu.wpi.first.wpilibj.RobotBase.initializeHardwareConfiguration(RobotBase.java:170)
        at edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:182)

The temporary partition (/var/volatile/) is being filled for some reason, so that there is only around 2.4 to 2.6 MB free (it varies). This makes it so there isn't enough space to extract the WPILib HAL library. I assume this is caused by your library, as there is nothing in my code that writes to a file AFAIK. The problem goes away if I revert to the commit before I added in Pathfinder.

EDIT: Thinking about the problem more, my current hypothesis is that the core dumps and hs_err_pidxxxx.log files are being written to the temporary directory (the error message says they are being saved to "//", but I'm not sure what that means), and they are filling it up as the code restarts over and over. Eventually, this prevents WPILib from loading.

I would say the issue is definitely the coredumps or hs_err logs. I'd recommend doing a reboot of the RIO and removing any tempfiles or logs. WPILib/NI made some changes to the 2016 image where it will keep trying to reboot your robot code using a watchdog no matter what. Unfortunately, that results in issues like this

Jaci 29-03-2016 23:22

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1565016)
I just saw your post, and I am probably running into the same problem. I'm a little confused as to how the coordinate system for Pathfinder works.

This is how I assumed it works, but I am probably misunderstanding it:
If the robot starts facing towards the direction I define as forward (ie. towards the opponent's castle):
Its initial heading is pi/2
A waypoint with x = 0, y > 0 and heading = pi/2 will cause the robot to drive straight forward.
A waypoint with x < 0, y = 0 and heading = pi will cause the robot to turn to the left and drive to the left, ending up facing left.
A waypoint with x < 0, y = 0 and heading = 0 will cause the generator to crash.
A waypoint with x = 0, y > 0 and heading = pi/4 will cause the robot to end in a position directly in front of where it started, but pointing to the right.

EDIT: I reread your post, and updated my examples.

The way it currently works is like so:
X+ is forward from where your robot starts.
X- is backward from where your robot starts.
Y+ is to the right of your robot where it starts.
Y- is to the left of your robot where it starts.

Positive headings are going from X+ towards Y+, Negative Headings from X+ to Y-. As for the actual following of the heading, that depends on where your gyroscope is zero'd to.

As with anything, these coordinates are useless unless you have the follower code to interpret them. X and Y coordinate directions can be flipped by just sending them to different motor outputs, for example

Ben Wolsieffer 29-03-2016 23:28

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Thanks, this should help fix my problem.

In the future, though, it might be good to have some way of gracefully recovering from this error, rather than segfaulting.

Jaci 29-03-2016 23:31

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1565037)
Thanks, this should help fix my problem.

In the future, though, it might be good to have some way of gracefully recovering from this error, rather than segfaulting.

I'll definitely see what I can do. From what I can tell it's a Div By Zero error, as some trigonometric functions give a 0 result for a 90 degree angle. Coupling that with the fact that Y doesn't change, it produces an error. Perhaps I can do a check for if it's 90 degrees to adjust it to something like 89.5 and print out a notice message.

ozrien 30-03-2016 11:25

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Hey Jaci, nice job! I'd be curious to know if anyone has tried using pathfinder in conjunction with Talon SRX's motion profile streaming mode. I think it would be pretty simple to stream the generated points to talons using kMotionProfile control mode.

Jaci 30-03-2016 11:31

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by ozrien (Post 1565242)
Hey Jaci, nice job! I'd be curious to know if anyone has tried using pathfinder in conjunction with Talon SRX's motion profile streaming mode. I think it would be pretty simple to stream the generated points to talons using kMotionProfile control mode.

In my original repo I was using to test the feasibility of Pathfinder, I did give it a test with the Talon SRX's and it worked quite well. It would be in Pathfinder right now, but all my SRX's are on the robot, so it'll have to wait until after champs before I can merge it upstream :P

Ether 30-03-2016 11:46

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1565034)
The way it currently works is like so:
X+ is forward from where your robot starts.
X- is backward from where your robot starts.
Y+ is to the right of your robot where it starts.
Y- is to the left of your robot where it starts.

Positive headings are going from X+ towards Y+, Negative Headings from X+ to Y-.

Not a big deal, but I'm curious why you chose the above convention?

Quote:

Originally Posted by Jaci (Post 1565039)
...From what I can tell it's a Div By Zero error, as some trigonometric functions give a 0 result for a 90 degree angle. Coupling that with the fact that Y doesn't change, it produces an error. Perhaps I can do a check for if it's 90 degrees to adjust it to something like 89.5 and print out a notice message.

It seems like there has to be a better way. Quite often, it's possible to make a small change to the order or method of computation to completely avoid those kind of errors. And if not, isn't there a way to trap floating point errors and make an alternate calculation in an exception handler?



kylelanman 30-03-2016 12:46

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by ozrien (Post 1565242)
Hey Jaci, nice job! I'd be curious to know if anyone has tried using pathfinder in conjunction with Talon SRX's motion profile streaming mode. I think it would be pretty simple to stream the generated points to talons using kMotionProfile control mode.

We are attempting to do this. We'll be working on it off and on at the Smokey Mountain regional this weekend. Due to other priorities I don't know if we will be functional by the end of the weekend or not. We may end up using pre generated profiles oppose to generating them on the fly.

Jaci 30-03-2016 20:04

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Ether (Post 1565258)
Not a big deal, but I'm curious why you chose the above convention?

I chose that system because it seemed sensical if you view your robot starting from the midline and viewing the field from top-down. Again, you can change the followers if you want to modify the coordinate system

Quote:

Originally Posted by Ether (Post 1565258)

It seems like there has to be a better way. Quite often, it's possible to make a small change to the order or method of computation to completely avoid those kind of errors. And if not, isn't there a way to trap floating point errors and make an alternate calculation in an exception handler?



There most likely is, and I will be testing approaches within the next few days. This only happens if you're trying to make a path with 90 degree exit angles without the Y value changing, creating a graph oscillates multiple 10s of meters in magnitude

AustinSchuh 31-03-2016 13:27

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1565511)
I chose that system because it seemed sensical if you view your robot starting from the midline and viewing the field from top-down. Again, you can change the followers if you want to modify the coordinate system

That means you either picked a left hand coordinate system, which is a pain to work with, or Z is down. Left hand coordinate systems have - signs that show up in weird spots in all the equations, and aren't common.

artK 31-03-2016 20:02

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1565034)
The way it currently works is like so:
X+ is forward from where your robot starts.
X- is backward from where your robot starts.
Y+ is to the right of your robot where it starts.
Y- is to the left of your robot where it starts.

Positive headings are going from X+ towards Y+, Negative Headings from X+ to Y-. As for the actual following of the heading, that depends on where your gyroscope is zero'd to.

As with anything, these coordinates are useless unless you have the follower code to interpret them. X and Y coordinate directions can be flipped by just sending them to different motor outputs, for example

The way the splines were defined in Trajectory-Lib (which it looks like you kept everything in it) was as follows:
  • The coordinate system used to solve it changes for each pair of adjacent waypoints.
  • The origin is your starting waypoint.
  • X+ is the ray from the origin to the second waypoint
  • This picture describes what the rest of it looks like.

If we define theta to be the angle between any heading in the spline and the x-axis for that spline, |theta| < PI/2, or else lose the polynomial solution we came up with. This is a weakness in using our geometry, but it works in most of the cases you would see and comes up with a clean solution.

If you wanted to make a curve that violates those properties, you could put an intermediate waypoint on the desired curve. This isn't a perfect solution, but it fixes the coordinate system to the point where it can generate splines.

Jaci 31-03-2016 20:21

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
This image describes Pathfinder's coordinate system, similar to what you'd find if you overlaid a cartesian plane on the game field, where the origin is where your robot starts.
On the graph above are plotted the waypoints:
[0, 0 @ 25 deg], [4.5, 2 @ 0 deg], [7.5, 3 @ 0 deg], [9, 1 @ 0 deg]

The heading is dependent on where your Gyroscope is zero'd to, which is usually where you set your robot up.

If you want to think of it another way, you could say that the X and Y axis are both parallel to the plane of the field carpet.

Ben Wolsieffer 31-03-2016 20:44

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I'm currently testing Pathfinder, and it seems to not be following the constraints specified in the config. It accelerates extremely fast, reaching a max speed of 25 m/s by the second point. This happens no matter what the max speed, acceleration and jerk are.

AirplaneWins 31-03-2016 20:58

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Im a little confused, what exactly do the coordinates mean, like how far is one unit. Can someone overlay this over a map of the field and show me?

Ben Wolsieffer 31-03-2016 23:38

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I was in a hurry when I wrote my last post (time restricted unbag periods are mixed blessing), so I'll try to explain the problem I am running into better now.

I was generating this waypoint sequence:
Code:

public static final Waypoint[] LOW_BAR_AUTONOMOUS_WAYPOINTS =
            { new Waypoint(0.5, 0.5, 0), new Waypoint(1, 0.5, Math.toRadians(45)) };

using this config (acceleration and max velocity are very low for testing):
Code:

public static final Trajectory.Config AUTONOMOUS_TRAJECTORY_CONFIG = new Config(Trajectory.FitMethod.HERMITE_CUBIC,
            Trajectory.Config.SAMPLES_HIGH, DRIVE_SUBSYSTEM_TRAJECTORY_PERIOD, 0.2, 0.5, 40);

When the trajectory was generated, it seemed to ignore the max acceleration and velocity values. The left and right trajectories accelerate extremely quickly, reaching 25 m/s within 0.01 seconds (also, jerk was around 24000 :eek:). The speed maxes out at 25 m/s. I never checked the source trajectory, so I don't know if the it had the correct velocity values.

I just realized that I was not using the real wheelbase width, only a dummy value (0.5 m), but this is still reasonable and should not have caused this problem.

Jaci 01-04-2016 00:34

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1565949)
I was in a hurry when I wrote my last post (time restricted unbag periods are mixed blessing), so I'll try to explain the problem I am running into better now.

I was generating this waypoint sequence:

When the trajectory was generated, it seemed to ignore the max acceleration and velocity values. The left and right trajectories accelerate extremely quickly, reaching 25 m/s within 0.01 seconds (also, jerk was around 24000 :eek:). The speed maxes out at 25 m/s. I never checked the source trajectory, so I don't know if the it had the correct velocity values.

I just realized that I was not using the real wheelbase width, only a dummy value (0.5 m), but this is still reasonable and should not have caused this problem.


I just generated a source trajectory with the values, and it seems absolutely fine, so I'd instead suggest that the issue is with the follower instead. The only thing I can think of is that the encoder values or kV or kA terms are incorrect in your follower, causing the issues.

Jaci 01-04-2016 00:37

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by AirplaneWins (Post 1565899)
Im a little confused, what exactly do the coordinates mean, like how far is one unit. Can someone overlay this over a map of the field and show me?

All the values pathfinder accepts can be in any unit you like, but they have to be consistent (i.e. if x/y is in feet, velocity must be in feet per second). We tend to use Meters as our units in most cases, but there's nothing stopping you using feet.

If your robot starts perpendicular to the midline (i.e. facing the outer works), X+ will be facing towards the tower, and Y+ will be facing the secret passage. You can flip these coordinates by reversing which motors each value goes to in your follower.

Ben Wolsieffer 01-04-2016 08:25

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I'm pretty sure the problem is not in the follower, because I found these velocity values by looking at the generated trajectory with the debugger. I will try to write a test application today to see if I can figure out what's wrong.

Maybe it has something to do with generating multiple trajectories at the same time. The robot has a thread pool generating 6 trajectories at once when it starts. Does the generation use any global variables that would cause race conditions?

Jaci 01-04-2016 08:39

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1565985)
I'm pretty sure the problem is not in the follower, because I found these velocity values by looking at the generated trajectory with the debugger. I will try to write a test application today to see if I can figure out what's wrong.

Maybe it has something to do with generating multiple trajectories at the same time. The robot has a thread pool generating 6 trajectories at once when it starts. Does the generation use any global variables that would cause race conditions?

it shouldn't do. I'll take a look when I get a free moment. I've filed a bug report against myself here for now

Ben Wolsieffer 01-04-2016 11:09

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
I was able to reproduce the bug on my computer. The source trajectory that is generated is fine, but when the TankModifier is applied, the really huge velocities appear. My testing has shown that it happens whether or not multithreading is used.

Jaci 01-04-2016 11:16

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1566045)
I was able to reproduce the bug on my computer. The source trajectory that is generated is fine, but when the TankModifier is applied, the really huge velocities appear. My testing has shown that it happens whether or not multithreading is used.

Try this newest release. It fixes successive generations of trajectories and may solve this issue as a result. If you have any further issues, please direct them to the Github Issues page

https://github.com/JacisNonsense/Pathfinder/releases

Ben Wolsieffer 13-05-2016 23:44

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
1 Attachment(s)
I finally got the time to get Pathfinder working (hopefully we will be able to use it at BattleCry@WPI), and here is a demo video of our robot following a simple trajectory that is similar to what we will use to get over a defense and line up for our auto shot.

https://youtu.be/m4pbv1_FC5I

Also, I attached a picture of a web interface I wrote (using pynetworktables2js) that allows me to see how well the robot is following the trajectory and easily tune the parameters. (Also, disregard the weird looking data, I was working on a problem when I took the screenshot)

Jaci 14-05-2016 00:03

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1586585)
I finally got the time to get Pathfinder working (hopefully we will be able to use it at BattleCry@WPI), and here is a demo video of our robot following a simple trajectory that is similar to what we will use to get over a defense and line up for our auto shot.

https://youtu.be/m4pbv1_FC5I

Also, I attached a picture of a web interface I wrote (using pynetworktables2js) that allows me to see how well the robot is following the trajectory and easily tune the parameters. (Also, disregard the weird looking data, I was working on a problem when I took the screenshot)

Looks good! What are you using to generate the graphs?

Once our robot lands back in Aus I'll see if I can do a demo with it, after my exams of course :P

Ben Wolsieffer 14-05-2016 00:07

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by Jaci (Post 1586590)
Looks good! What are you using to generate the graphs?

I am using Plotly.js, which is being fed data from NetworkTables. I'm starting to wonder if there is a better alternative, though, because it seems to have trouble dealing with data that updates many times per second.

virtuald 14-05-2016 11:34

Re: Pathfinder - Fast Motion Profiling for Java and C++, Tank and Swerve Drive
 
Quote:

Originally Posted by lopsided98 (Post 1586592)
I am using Plotly.js, which is being fed data from NetworkTables. I'm starting to wonder if there is a better alternative, though, because it seems to have trouble dealing with data that updates many times per second.

Have you tried flot?


All times are GMT -5. The time now is 04:59.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi