Today, we made the jaci’s pathfinder run. However, when we set the first waypoint to 0, 0, 0 (x, y, angle) and the second one to 0, 0.6, 0 (x, y, angle) -> to drive straight forvard, the code is crashing again with the following message:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0xab322158, pid=4515, tid=0xb52c1470
# JRE version: OpenJDK Runtime Environment (8.0_131-b57) (build 1.8.0_131-b57)
# Java VM: OpenJDK Client VM (25.131-b57 mixed mode, Evaluation linux-aarch32 )
# Problematic frame:
# C [libpathfinderjava.so+0x6158] pf_trajectory_fromSecondOrderFilter+0x88
# Core dump written. Default location: //core or core.4515 (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:
# If you would like to submit a bug report, please visit:
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
what does “problematic frame” mean?
I have seen similar - maybe the same - issue and the solution to that was to lower the dt variable in Trajectory.config to 0.005. However, this solution did not work for us. Trying to set the exit angle to 0.0001 (to avoid unexpected division by 0) is also not working.
If I remember correctly, Pathfinder is pretty opinionated about X being your forward/backwards location and Y being left/right location. Going from (0, 0, 0) to (0, 0.6, 0) with a tank drive would therefore be impossible, at least without any easing points.
SIGSEGV means the processor threw a Segmentation fault during execution. The “problematic frame” referenced is the function call the execution was inside of when the fault occurred (czech out the C Runtime stack for more info). Notice that since the .so object is referenced, you know it’s happening outside your java code, and within pathfinder. The portion of the error message “The crash happened outside the Java Virtual Machine in native code.” also hints at this.
A brief note here, if you didn’t know: Java runs inside a Virtual Machine (the JVM), a program whose job is running java programs. It is in many ways a “buffer” between your code and the actual silicon of the processor chip. It does have the ability to call “Native Code”, which runs directly on the processor. Native code generally runs faster, but is harder to build and write and debug. Jaci I believe builds the more computationally intense (aka “fun”) portions into native code. As you’re seeing, when something goes wrong in native code, the error messages aren’t as nice as when they happen in java (all due to the lack of the JVM).
Without the source code for pathfinder and a debugger that can interpret the debugging symbols that may or may not be present inside libpathfinder.so, the main thing you can deduce from the error is that there was a memory dereference issue inside of the pf_trajectory_fromSecondOrderFilter() function.
Sometimes, things like this happen when a library is not robust against arbitrary inputs. Though it’s not a graceful failure, I could imagine a few ways that commanding a tank bot to do a pure strafe could cause poor results during a path calculation. Jaci’s pretty active around here though and can probably provide way more input.
I did some graphing and it seems that you are right about switching X and Y axis - we generated and executed some other trajectory and I graphed the path with and without inverted X and Y and the robot seems to be acting as the graph where Y is being the left/right direction