I also updated the C++ and Java code some. For C++, this meant making it
compile and adding in the framework for the closed-loop control of the
motor. For Java, I updated the JNI bindings with SWIG and created an
GetTemperature accessor function to demonstrate how to use the accessors
because swig does funny stuff with pass-by-reference functions.
Change-Id: If51bf61d0a9bc65a8d497f8d91a5be8d6ff4fdcc
Currently, the JNI bindings are generated by Swig and, unfortunately,
the interface available through Java is lower-level than that for C++
(ie, direct access to the ctre code through the JNI bindings, rather
than an interface on top of that), but it does work.
See eclipse plugins for some short samples.
There are a couple of short unit tests as placeholders.
Still needs some cleaning up.
Change-Id: Iae2f74693ca6b80bf7d5aca0625c66aa6e0b7f85
Added quick samples for C++/Java CAN Talon stuff.
Change-Id: I3acb27d6fd5568d88931e0d678c09973d436735d
Lanucher immediately attempts to attach 20 times before giving up
and waits 2 seconds between attempts.
Change-Id: Ib0a70b8bbf5e90d5a733ea4e0d6b17d91b36db87
The build scripts were still calling the tail command for following the log
file, even though we're now using netconsole. I've removed them.
Change-Id: I48498c1ef338f99130e447097081db92b394e1aa
Add IMAQdx and its dependencies
Change-Id: I6befa563e96db224db83fb90985c86eb3e8d4f3e
Add a "CameraServer" class for C++
This class allows the driver station's camera viewer to interact with
a C++ program. It includes both an automatic mode to send images from
a webcam to the dashboard in a background thread, and an option to
manually feed it IMAQ images.
Change-Id: I54fdb164c00dce165859c22f435be647dc9927cc
Plugin was retrieved from https://github.com/mstoeckl/riolog.git with minimal changes to
make it compile.
Change-Id: I340d77c69fe7598595deeaba8d4cd9414b971399
Anywhere in the sample programs where there was just a
isOperatorControl() in the while loop for Teleop, added an "&&
isEnabled()".
Change-Id: Ib81e8bab79923e262c314a073a591855cbf06846
There is still a bug where the examples have been updated to use 0 based
joysticks, but the simulation libraries have not been updated. I'll fix
that as a separate commit focused on fixing the joystick APIs.
Change-Id: I3b358e67b7fa18b30d1fd2b53098659cfefdfd76
Reads values from quadrature encoder and displays them on the
SmartDashbord.
Also added Encoder with Motor Control example, which is identical to the
Motor Control sample but displays an encoder value on the
SmartDashboard.
While final would seem to make sense for RobotMap values (as these values
should be constant at runtime), RobotMap values are often not truly final
in the Java sense of the word, as on real robots they often change between
project builds (e.g. they often can and will be changed by teams as wiring
changes on the physical robot).
Unfortunately, incremental compilation in Eclipse follows Java rules, and
doesn't track cross-module dependencies on final variable values, resulting
in very non-intuitive behavior when a final variable's value is changed:
other (unchanged) Java modules using the final variable are NOT recompiled
(as is necessary to pick up the new value), and there is no easy way to
force recompilation of every Java file in the project.
Change-Id: I75b13aaf4f4a687698f853d5e11eef5f904716ea
