worthington-robotics / 2018javarobot Goto Github PK

We need to get a functional "gyro lock" written for java. need to investigate how to read a navx gyro in java then use it to calculate a rotation feedback for driving the robot. It should be completed by next week.

Max and i have been kicking around the idea of using a color sensor to find some of the lines on the floor to use as a reference. The first sensor we are trying is the APDS-9960 a gesture /color sensor controlled over I2C. I have found the documentation of the I2C classes in java as well as the sensors own arduino library to use as an address / register / byte reference.

WPILib I2C Reference: http://first.wpi.edu/FRC/roborio/release/docs/java/edu/wpi/first/wpilibj/I2C.html
Sparkfun arduino library:
https://github.com/sparkfun/SparkFun_APDS-9960_Sensor_Arduino_Library/blob/V_1.4.2/src/SparkFun_APDS9960.cpp
&
https://github.com/sparkfun/SparkFun_APDS-9960_Sensor_Arduino_Library/blob/master/src/SparkFun_APDS9960.h

currently the autonomous list works but will need changed to the autonomous variants later. The getter method will return null if the driver station tells no auto

As the main branch stands last night, the serial does not crash the rio. However having the read inside the periodic method does seem to block the others from executing until it times out. This is evidenced by the drive train timeout error from the I/O watchdog. This can probably be fixed by spawning a thread independent of the ticking system WPI has implemented to ensure strict timing. During our Roborio bug, Max came up with a solution to this issue already (without knowing it) and may have put it somewhere.

Roughly two days ago, while testing our serial code, we began to notice a strange behavior from RIO 1. It would hard crash approximately four minutes after being powered on. The hard crash could only be resolved by re-booting the device and waiting for it to crash four minutes later. After several iterations of changing and removing our code (and still crashing), we arrived with a blank WPILIB project that crashed inside about 35 minutes. The error does seem to be related to memory. Yesterday afternoon, I was able to find a crashlog in the admin user directory. I have created a gist of the crashlog to be shared. The crashlog seems to be focused around some sort of memory issue.

gist: https://gist.github.com/coalman321/702367144e1c5d40bfd6ed8e24fcabdf

Even stranger still, after moving the same code that crashed RIO1 onto RIO2, RIO2 was observed to be stable for over two hours(it never crashed but I had to leave). I am wondering if it is a bad block in memory or a software issue in WPILIB.

Any thoughts?

EDIT:
I also discovered this line in the crashlog. It appears to be that no garbage collection is actually running.
GC Heap History (0 events): No events

This link points to the line were it is in the log:
https://gist.github.com/coalman321/702367144e1c5d40bfd6ed8e24fcabdf#file-hs_err_pid6327-log-L89

In the next coming week, we need to start developing roughly 12 different autonomous functions for use in the season. You will be divided into two phases, planning and execution.

Planning:
Natalie and Marika will work with Karns & the drive team to determine the possible autonomous routes. they will then be laid out on a graphical representation of the field for use as a reference for other teams we will play with. Make them look nice.

Execution:
everyone else will be tasked with developing one of the routes to run on the robot using the commands we already have in place & or implementing new ones.

This is our mission for the next two to three weeks.