Quote:
Originally Posted by Necroterra
What kind of delay is there on the interrupt system if you are running everything default, no thread priorities, on Java? I feel like 0.1-1 ms is more than a fast enough response time for virtually every FRC application, considering that other methods like CAN can have >10ms of cycle time, but I know think I remember hearing that you guys had overclocked the CAN rates too.
|
Most teams will never notice latency issues. 971 happens to be special in that we design complicated systems which require tight timing to make work at the levels of precision and reliability that we target.
Tom from 254 reports that he was able to get it down to ~2 ms in Java. I have never used Java on a FRC robot, so I can't confirm or deny. When 254 was doing thread.sleep, to time a loop in a separate thread, he reported up to 0.25 seconds of latency.
Latency can be modeled as another source of noise. We used the fast response time to zero our claws in 2014, and other systems this year. Our control loops could hit somewhere in the order of +- 0.002 radians, and measure another order of magnitude more precise than that. If you are zeroing at 2 rad/sec, that means that you are going to add 0.002 rad of noise per millisecond of error. To hit 0.0002 rad/sec (below your positioning accuracy by an order of magnitude), you need to move at either 0.2 rad/sec or have less latency.
I'm not sure where you heard the rumor that we over-clocked CAN, but we chose to not use CAN after benchmarking the latency of it and looking at the other options (and it being new). We couldn't figure out how to synchronize our control loops with the CAN send cycle, and after hooking up some external CAN monitoring equipment from my work, saw high peak latency on the bus. PWM is a known quantity, so we moved on. Reading sensors over CAN has the same issues you described, so we kept them connected to the FPGA so we could read them faster. (The FPGA is memory-mapped into the process's address space, which makes accesses fast.)
Quote:
Originally Posted by Necroterra
Also, I'm not super familiar with JNI or the fancier parts of WPILIB, but it looks to me like you just pass your Handler function into the FGPA, which I assume would be watching it on a specified thread already. It might be different if you are working with WPILIBC though, since WPILIBJ just stops once you hit the native calls and I don't remember where/if you can look up with implementation.
|
The WPILib C implementation uses NI's library, which spawns a thread, does an ioctl until the interrupt happens, and then calls a handler function. Similar to you, I don't know how that interfaces with the JNI/Java code and the GC.