lsrobotics / 2016robot Goto Github PK

whops. I forgot to remove the revX example code form the project. This is just a reminder that I have to remove it tomorrow

It looks like development of this recorder is reaching an end. If we want other teams to use this we better clean up the code a little bit (if it needs to be) add Javadoc, maybe add some support for other types of joysticks, and eventually upload this to a separate repo.

Right now .travis.yml is set up to perform the target "Test" section at the bottom of travis_build.xml, which is empty.
I want to get travis_build.xml set up to compile all code, and run any unit tests in the UnitTests folder, returning 1 if any fail.
This way, any time someone makes a pull request to our repo, it's run through a series of tests ensuring the changes don't break anything (see the attached picture)

Designing the unit tests is another issue.

So Connor and I figured out sth in run() caused the delay of code execution in autonomous. Tomorrow we must figure out a way to time the delay and define timeStep variable. The problem is 1) where it is happening 2) is the actual delay arithmetic ( which means a static value or a static value of increase will solve the problem or geometric (exponential? This well explains why the robot will be relative slow at first and relatively fast in the end. The problem is after we added an additional while() loop in run() it actually disappeared. Not to mention that 3) the Thread.sleep() actually shuts autonomous down for timeStep amount of time and actually hampers the robot from general execution. So Connor added a while loop using timeStep to execute the code timeStep times to solve the problem, and Thread.sleep() is set to one miliseconds. The problem is 1 is still too high however if we comment the entire Thread.sleep out it becomes too fast. Therefore a Delay timing method is needed.

Two possibilities

1. Thread part went wrong
2. Thread.sleep does not recognize negative long variables ;most likely.
3. Some sort of ghost is mocking us

Files not added to github. Additionally I made a mistake in the way that I start each thread.

@Connor-Devitt

Originally, ActionBased.java and Robot.java had their own gamepad objects, each initialized to port 3; The recorder would access the gamepad object and record all buttons as having a magnitude of 0 (makes sense considering no calls to getPhysicalState() were made on that object).

I changed it so both classes used the same gamepad object- bad idea. Now an exception is thrown when the recorder tries to access any of the gamepad state variables while recording. I added Lock.java thinking that restricting access to the gamepad state variables would fix the issue- it didn't, exceptions are still being thrown somewhere.

Alex and I had to leave before we could look further.

Right now if two separate recordings are made and the filename is not changed, the two will be stitched together in the same file and played back as if they were both made at once.

We'd definitely like to keep this feature but the what we're trying to do should be clearly reflected in the code.

The Recorder should be able to:

• [Overwrite Recordings of the same file name]
• [Append to Recordings of the same file name]
• [Automatically generates names for new recordings (eg if we record into a file called r1.rcrdng, our next recording will go into r2.rcrdng, and so on)]
• [Allow the user to specifiy the name of the recording (without having to rebuild the code)]

I'm not sure how to communicate these things to the RoboRio without making another app on the driverStation, maybe the driverStation application has a way of accessing +sending keystrokes.

We can probably use RevX to correct for mistakes in auton, control sensitive actuators, etc

Currently GRIP GUI interface on windows can't connect to mjpg-streamer on Raspberry pi and kept on displaying a frame rate of 0. The WPI guys have no idea why it is. We'll probably need to play some guess-and-check games to get it working.

Currently it's working on the raspi version though, although it still won't give a hint of how it works.

In order of priority:

 1. Add functionality for any additional mechanical functionality
 2. Make autonomous more robust (More defenses, easier to record, shoot ball if physically possible)
 3. ADD USELESS STUFF TO IMPRESS JUDGES (Priority: low)

Add code for the arm mechanism

I noticed the default kernel network stack performance is too slow. Proper tuning shall be conducted via sysctl.conf - this shall be done in a separate repository to store all the config files.

So now the DIO ports in Ultrasonic are hardcoded as a constant in the class 'SonicRangeSensor'. I wish to have a way to dynamically define them as well as having multiple ultrasonic sensors working together.

The autonomous is not working well on turning.

The code written on Wednesday, changes made by @Connor-Devitt on TCP Client hadn't yet been pushed to the remote tree.

The git push shall be done tomorrow as soon as anyone gets into the shop. Meanwhile, No changes shall be made until that specific commit is pushed to the remote branch.

Every time when the class is included, build fails. The error seems to be that it's referring to a deprecated method.

Suggested troubleshooting action: include the sourcecode files in the eclipse workspace rather than downloading the preconfigured .jar file. The only way to troubleshoot the thing is only to look at the declaration.

When Autonomous is initialized it calls actionplayback, which downloads the commands from the driverstation, modifies the state of the controller, and calls teleopMaster, all without returning.

If we want the code to be utilizable by other teams, probably some documentation under wiki will be necessary? If possible I can complete the task.

Due to 1) Raspberry Pi Generation 1 performance reasons 2) Network congestion reasons the fps is extremely low and GRIP is not displaying streamings, only displaying images.

Proposed problem solvers: 1. Upgrade RPI to RPI 2

2. Optimize the built-in linux network stack by tuning sysctl.conf

The Travis-ci is a "continuous integration service." Basically every time we make a change to the GitHub, or every time someone makes a pull request, Travis will check to see if it builds and if it passes a few tests. I'm still figuring it out, but right now Travis can't even build it. This makes sense, as this isn't typical Java code.

Imagine the entire field as a coordinate plane. The y values are the vertical length while the x values are actually the horizontal width. The point where the robot is started is mapped by (0,0). The goal and defenses can also be mapped to their relative coordiates according to then point of origin. In this way we can locate our location on the field using a GIS-like system and therefore take according actions.

Also, since the general structure and length of the field is the same every time in each competition, this method will be generally applicable.

The recorder can now record actions and play them back autonomously, with little to no differences in timing.
However, the recorder seems to stop before it completes every action in the recording. Ex, if the recording is to move forward, pause, move back, pause, and move forward again, the robot will move forward, pause, and move back.

1. Change lambda expressions to support JRE 1.7
2. Get input/output working
3. Conversion between byte[] array and string/double array
4. Async through multithreading but not through nonblocking

The team bear is not functioning in codes! Must get the bear awake next time! 🐻

The ultrasonic class is working, but this physical sensor settings still need proper debugging to work.

Add classes to the UnitTest folder, with methods labeled with @test that test the logic of the robot code.

Worth looking into.
Check this page.
We have a Microsoft Lifecam HD-3000.

It prints out some error involving networktables, and a software version mismatch

I left early today, I didn't see any commited codes today to the remote tree. Again try avoid to do any changes before the codes get committed.

Autonomous interface should define three methods: init, setAutonState, and doAuton.
Init will replace Actionplayback and will initialized all autonomous related things (ie put the recording in a buffer)
setAutonState is called by robot.autonomous() and will stop auton if robot leaves autonomous mode
doAuton will either start the autonThread or start the main method of autonomous.

Everytime GRIP deploys to raspberry pi it throws an exception.
Error injecting constructor, java.lang.UnsatisfiedLinkError: no ntcore in java.library.path


The thing is their documentation is so crappy. I have tried creating symbolic links in /home/pi /home/lvuser and /home/sexystuff, didn't work.

Add code for the ball pickup mechanism

We'll have to figure out how to actually coorporate between Raspberry Pi and RoboRIo. So initially I thought we can connect robo to rpi using a usb-c cable, which will be faster than ethernet.

Connor and I added the TCP server and client under pacakges in.derros.netfang.tcp.server and in.derros.netfang.tcp.client. The code is building right now, but proper testing shall still be conducted.