The onTarget() method uses the average error and there might not be a valid value
until the PIDController runs once. This is causing commands to bail out early in
simulation.
Change-Id: I7bac9ecb847cbe4f378385b1a6998bba10147554
The GetSmartDashboardType() function defined by GyroBase was returning the
correct "Gyro", but the overrides in AnalogGyro and ADXRS450_Gyro were
incorrectly changing this, resulting in SmartDashboard not recognizing these
as being gyros.
Additionally, AddSensor in the C++ AnalogGyro was setting the name to Gyro
rather than AnalogGyro.
Change-Id: Ib2e31cd2712cc2bc26c8082ed760175d0ee80fb6
The current feed forward calculation is only useful for velocity PID controllers where F, the feed forward constant, is 1 over the maximum setpoint for the output. For motion profiles which use position PID controllers, the appropriate calculation for velocity and acceleration feed forwards is different. This change allows the user to provide their own feed forward implementation without having to rewrite the entire Calculate() function.
Both default feed forward calculations are velocity feed forwards. Suggestions for sensible feed forward constants are included in the inline comments.
Change-Id: Id175786f26bd342de52a1fae89595cbeba5dfc93
Years update, references to WIND_BASE were removed, and WPILib license was
moved to the root directory of the project.
If there was already a comment block, a year range through 2016 was created
using the first year in the comment. If there was no comment block, a block
with just the year 2016 was added.
Comments were not added to files from external sources (NI, CTRE).
Change-Id: Iff4f098ab908b90b8d929902dea903de2f596acc
Also remove m_mutex. It's no longer necessary because we ensure the automatic
thread is stopped while the set is being accessed.
Change-Id: I5994bbeba022a2ebd9e166fca369ebc8c229975c
This allows both greater than 72 minute (2^32 * 1 us) timeouts and also
gracefully handles notifiers across the FPGA time counter rollover.
Change-Id: Ibde0b903155f60b618b0ca4d5f8f6dd49f90b020
Also provide templated varags constructor for backwards compatibility and
ease of use.
Update PIDController to use new constructor, eliminating static function
CallCalculate().
Change-Id: Iaeae95aa5953f294f5debc5fc569ef6d4684f223
This removes redundant queue code from the C++ library.
The old queue code is still needed by simulation, and as the delta between
the simulation and athena headers has grown significantly, this splits the
header into two separate files.
Change-Id: Ia76b38337a25eb9d4890b3eb9bd76b1cbda7f285
DriverStation was being added to the singletons and also as a const
member variable. This made it so that on program exit, it was
getting double freed.
Change-Id: I87f8260615dc31d57ce7c7204c1dfde22973ad51
- CANJaguar also touched up to report it can't do the new control mode (just like with follower).
- New third optional param for talon c'tor to speed up enable control frame.
- The pulse width routines have been moved to where the script generator puts them. No actual changes there but should help Peter integrate the latest code generator.
Last feature additions for TalonSRX HAL for FRC2015-FRC-2016 season.
-HAL driver uses control_5 frame if firmware supports it. This allows teams to see/confirm control settings taking effect before enabling the robot.
For example selecting the sensor type and going to web-dash to check sensor values now works without having to enable the robot.
-Motion profile HAL routines added. Tested on Single-Speed Double reduction (with slave Talon too).
-Start moving ctre frame defs into a new common header (better then shoving a bunch of struct defs at top of module).
-New child class in CANTalonSRX for buffering motion profile points. Not sure it would be best to leave it as is or make another module. It's trivial now so I thought that was acceptable, (in future it will likely possess compression strategies => no longer trivial).
Change-Id: I803680c1a6669ca3f5157d7875942def6f75b540
Also fix DigitalGlitchFilter usage reporting for C++ (only report on
construction rather than on each call) and add for Java.
Change-Id: I73758b16d81c40442c4acec43e0aa6804b2ba250
The previous commit missed the MindsensorsSD540 value.
Remove wpilibc/Athena/include/NetworkCommunication/UsageReporting.h copy; it
was not actually used (all references except the one in DriverStation.cpp
had been commented out), and has been superseded by the one in HAL.hpp.
Change-Id: I51e2eafa85ee5e40050d702aa0bf69171e887a60
This is a digital gyro interfaced via SPI. Uses the HAL SPI accumulator.
Basic code function successfully tested on a ADXRS453.
Change-Id: Ibc0c7db9964c041fb1e04af4db17e3310ea83c04
The constructor sets m_channel to UINT32_MAX and reports an error if the
channel index is out of range (or CheckDigitalChannel fails for some other
reason). A Get() following this would result in a crash because it wasn't
checking StatusIsFatal().
The new behavior now checks StatusIsFatal() and simply returns false.
Change-Id: I15529401294e4ccd1e09df834e02cca367fab67c
This is a poor man's version of the multi-instance Notifier support in
the higher level languages. It's intended primarily so that notifiers
can be created internal to the HAL.
One benefit of this change is that the current FPGA timestamp is passed
as the first parameter to the ProcessQueue function (rather than the
useless interrupt mask).
Caution for other languages wrapping the HAL: this adds a parameter to
initializeNotifier().
An atexit hook is used for safe cleanup at program termination.
Change-Id: I782b3a74c10215588ae9b7191906fb4186a81028
All the Error and assert calls were using const ::std::string & arguments.
When provided with a char*, the compiler was creating a temporary string
object to pass in. This was triggering mallocs everywhere, even in the
fast paths.
Change-Id: Ie0ad1f240334de677618086bddd64113c56aae6e
Implement GetAllSolenoids in the HAL so that SolenoidBase doesn't have to
read each solenoid individually.
Change-Id: I85559565949f7a7119ead410187235636a63f0ed
Having the HAL take a NATIVE_MULTIWAIT_ID without any way to get that
structure from extern "C" code is a problem. This makes it so it just
takes a MULTIWAIT_ID, and then grabs the native handle inside the HAL.
Change-Id: I06da18ba34adcea2f16e4e53da672f38be79e28e
Signed-off-by: Dustin Spicuzza <dustin@virtualroadside.com>
In the current HAL, once the port structures were created, there was no
way to free the structures. The way the C++ libraries were written this
wasn't a problem, since it grabbed a copy of each and stored them in an
array on bootup. However java does not do this, and grabs new ports
every time an object is created. This causes memory leaks if an object
is ever disposed in java. The same thing looks to be happening in
python, and C# does it too currently, but that would change if this gets
merged.
Adds java memory management fixes
Adds memory management to AnalogInput and Analog Output C++
SolenoidPorts and Digital Ports are all hold static arrays with their
port pointers (although solenoid overwrites them if a new solenoid on
the same module is created), however analog always grabbed new pointers.
I would fix the solenoid one, but I don't know what the ideal way to do
it would be.
Silently ignores free(null) calls by checking passed parameter is non-null.
Change-Id: Id32993b57b53f896e46e55c97541d3bd90b52648
For the previous couple of months, the PID tests have been hanging.
The reason that the tests have been hanging lies with the Notifier,
not the PID controller. Basically, a deadlock was occuring during
Notifier destruction when the notifier destructor was called while
the notifier interrupt handler was being called. Because the low-level
interrupt manager waits for the interrupt handler to finish executing before
disabling itself, the notifier destructor would not exit until the
ProcessQueue function finished. However, at the same time, the handler
was attempting to lock the queueMutex before continuing; the Notifier
destructor had locked the queueMutex while wrapping things up, meaning
that the last run of the handler would not complete until the destructor
did, resulting in a deadlock.
In order to repair this, I reduced the scope of the lock on the queueMutex
in the destructor so that it only locks when absolutely necessary. This
should work now.
This bug was likely introduced over the summer when we updated to stl
mutexes and locks, which may have messed up the original lock structure.
This likely did not affect any teams, as it can only occur if you are actively
destroying every* Notifier object present and if the destructor happens to be
called while the handler is being run.
*Note: the component of the destructor causing issues only ran if the last
Notifier object is being destroyed.
Change-Id: I38ba4e60816a2a8d523e927c25378390a0755444
