Manually specifying a sync group causes that value to be
passed in all of the speed controller Set() calls, and
CANJaguar::UpdateSyncGroup() to be called afterwards.
Change-Id: I365216463e3dd57b3fafb1bed898fb0da4b08793
Rewrote CameraServer to use the new USBCamera implementation and get rid
of some unnecessary copying of the entire image.
Change-Id: I877750e990b6159c0aaf829df62b253a171fbada
Change-Id: Iaa4062ec124b968b27e7c812cc754032fcb354d2
Add methods to retrieve the FPGA index for counters and encoders and return the encoding type as an integer
Change-Id: If04dc291f39a9b331495d2b97a8b87d3ded71280
The API is basically the same as the C++ one.
The JNI function for Priv_ReadJPEGString_C was manually renamed, since the
python scripts don't name the C++ functions correctly, causing an
UnsatisfiedLinkError at runtime. If further changes are made to the bindings,
either the method will have to be manually renamed again after the code is
regenerated, or the python scripts will have to be updated.
The old ignored edu.wpi.first.wpilibj.camera package was removed.
Change-Id: Icd37fc15c7bb41061568c3b2f580c6765cbf0300
Most of the old vision code still compiles with minimal changes. I haven't
tested it extensively, since the AxisCamera class isn't done, but it
should work, as it was barely modified.
Java bindings are still TODO, since they used some JNA stuff that probably
won't work now.
Change-Id: I8edf991410cb30b932379f277cee9d329ee35009
They already existed in Labview, so this will keep parity
New C++/Java funcs
ConfigFwdLimitSwitchNormallyOpen
ConfigRevLimitSwitchNormallyOpen
Change-Id: Ifd65ead827838e7158f7261c67adc3738c72eabf
A simple improvement was to only perform the disable-before-next-set strategy if the caller's request mode is not equal to the current mode.
To keep things simple, SetControlMode was renamed to private method ApplyControlMode so we can still invoke it from c'tor.
Then, the new impl'n of SetControlMode() just calls ApplyControlMode() when caller's request mode is different. That takes care of direct-calls from team source, and indirect calls through enableControl().
Applied to both c++ and java.
Tested in java so far...
Change-Id: I934c06c5339d933918470659acd635e12eb4d113
Java...
added setStatusFrameRateMs() to modify the frame rate for status frames
added missing func that already exists in c++
isFwdLimitSwitchClosed()
isRevLimitSwitchClosed()
getNumberOfQuadIdxRises()
getPinStateQuadA()
getPinStateQuadB()
getPinStateQuadIdx()
added getAnalogInRaw() that doesn't count overflows (for potentiometers).
added setStatusFrameRateMs() to modify the frame rate for status frames
added getBrakeEnableDuringNeutral()
C++...
added GetAnalogInRaw() that doesn't count overflows (for potentiometers).
added SetStatusFrameRateMs() to modify the frame rate for status frames
added GetBrakeEnableDuringNeutral()
added kLimitMode_SrxDisableSwitchInputs to CANSpeedController::LimitMode
Patch set 2: Joe Ross, fixed two javadoc errors
Change-Id: I0bf871e138953de60eeacb547dc359f2125b1327
Increased wait delay to 4ms to cover worst case delays for solicted signal getters.
Specifically....
-Get firmware vers
-Get P,I,D,F gains
-Get IZone, Get CloseLoopRampRate
-Get IAccum (integral accumulator)
Change-Id: I313ea984832cce5182af8e5af5e775837fd54fdc
The param is capped in the HAL C++ class to [1ms, 95ms] so that zero and negative periods are caped to 1ms, and so that caller can't pass an absurdly large value, which causes TALON is appear disabled.
Change-Id: I4207194be25a33bbd6ad281a75301ce6684659a5
Adds isEnabled and getSetpoint functions to CANTalon classes.
Sets m_controlEnabled=false in Java if changeControlMode(Disabled) is
called.
Change-Id: I08fd0972df22ad83c5578dd43dd6b3536f3b365b
Added Get/clear routine for IntegralAccumulator
Added missing status check in GetFirmwareVersion(). I don't expect this to affect anything.
JAVA
Renamed getRampRate to getCloseLoopRampRate in java to match the set routines in java, and match all routines in cpp.
Added GetFirmwareVersion to java to match cpp.
Added Get/clear routine for IntegralAccumulator
Retested all three routines in java.
Change-Id: I4ce9d9c87a379b9d4a76aae226e2072876218688
Used to be that if you called Set less than ~20 ms after changing the
mode, potentially unwanted behavior could ensue.
Change-Id: I27cb3603286d8fddd894649787d88c0446b00615
