Wait, actually, if you gamma shift the image you can see what looks like vents and the sillowette of something circular in the center, ao maby a LL competitor.
2 Likes
I appreciate your efforts, but the issue with Java teams using C++ vendor code is not just that it’s hard to read, it’s that it’s impossible to experiment with. Java teams know how to experiment with Java code, but they don’t know how to modify and build the C++ code (if the source were even available). So if a student is puzzled about what’s happening in the vendor code, they’re stuck. I try to minimize these sorts of road-blocks for my students, especially road-blocks that are directly in the middle of the control topics I’m trying to teach.
You could say the same thing about any code that interacts with the rio using JNI in WPILIB. I really don’t think it’s a big issue to learn to read C++. It’s not that hard to understand compared to Java
7 Likes
I agree, I dislike the WPILib JNI stuff for exactly the same reason, and I’m hoping that the 2027 processor will enable us to remove it entirely, again, no offense to the folks who have put in an amazing amount of work to make the current potato-processor perform well using C++.
And to reiterate, it’s not about reading. Reading is not the same kind of learning as experimenting. If we wanted students to simply read about robotics, that wouldn’t need all this hardware.
I used the CTRE Swerve Library as heavy reference for custom swerve code this season, and personally, although the change to C++ makes that harder, I think the benefits of C++ outweigh the disadvantages. The whole point of the CTRE Swerve Library is to make high-performance swerve code easy and accessible to all teams.
The C++ change improves the performance, and allows Python and C++ API support. It basically just makes the swerve library even further accomplish it’s goals, and it continues to allow customizability through SwerveRequests (although without all of the performance benefits).
I think you are in a very tiny niche. Like. Less than 10 teams niche.
8 Likes
I doubt that will happen, for the same reason that RobotPy moved to wrappers around C++ functionality (it wasn’t because of performance) – writing duplicate versions of code in different languages is boring tedious work and nobody wants to do that (and for the most part, with RobotPy, nobody else did it).
8 Likes
That’s what I’m largely hoping we can do for simpler things, but perhaps not for some of the more complex math—given the lack of operator overloading in the language, Java math code with complex types can be near unreadable, and having a Java specific implementation results in a maintenance burden of writing the code twice and having both implementation and bug divergence. In some situations it can boil down to a tradeoff between somewhat worse pedagogy (for WPILib, the code is still open to read, just not in Java… and is probably more readable in C++) or buggy/low performance/hard to maintain code, and if it reaches that point I think the less buggy code is going to be the better path for the majority of teams.
We will definitely not be hoisting big complex implementations like NetworkTables or CameraServer to pure Java. The duplicate implementation burden is far too high in these cases.
12 Likes
Other than WPIMath (Which is often done for performance reasons, and could see some changes in 2027 like Peter said), the rest of the JNI isn’t for performance reasons, but for code sharing or low level library access reasons. Maintaining 2 separate copies of network tables isn’t feasible, and cameraserver in Java probably just isn’t possible at all. Same thing with the HAL, which is mostly wrappers around the hardware libraries.
6 Likes
I do have some good news on this, our next beta release will include some changes that will allow custom SwerveRequests to take advantage of some of the performance benefits of the NativeSwerveRequests. Keep an eye on our changelog or subscribe to our RSS feed to get notified when a new release is available.
1 Like
yeah, i’m more forgiving of blackboxing stuff that i don’t personally consider core.
network communications? ok to be opaque.
robot behavior control flow? not ok.
Everything implemented in motor controller F/W is opaque, and this is a big part of the low-level control loops for many teams. There are always trade-offs…
4 Likes
Because nobody needs to. Any DC motor’s performace throughout its entire operating range can be characterized as a non-ideal gyrator with resistance and inductance, in which the non-idealness is captured from the difference between kT and kB. If you know these 4 constants, you can model a motor’s performance quite accurately, assuming thermal effects are not relevant. The extra torque coming from a motor reversing comes from the backEMF direction helping you (decelerating the motor), resulting in a much larger voltage difference across the motor (up to 2x the battery voltage, disregarding inductance and limits), allowing for more current to flow across the phases, vs its usual operating direction when accelerating, where backEMF reduced the voltage differential leading to less current being drawn.
Same as above. kb, kt, resistance, and inductance are enough to characterize the brake mode behavior. And inductance is typically ignored bc its usually negligible.
What FRC motor vendors really should be posting is the kT, kB, and effective armature resistance directly, rather than having derive them from the values they give us using inaccurate methods. Doing this will increase modeling & simulation accuracy, as these are the constants such models are looking for. The backemf constant isn’t quite the nominal voltage divided by free speed because free speed is influenced by friction, while the backemf constant is purely an electromagnetic constant, where the proper way to measure it is to spin the motor at a known RPM and check the backemf constant. The torque constant isn’t quite the torque at stall over the stall current, because stall current measurements can be inaccurate due to thermal effects and saturation.
1 Like
oh, yeah, that bothers me too. that code, i can’t even read. i can’t get meaningful logs out of outboard control, so i can’t help my students to understand what the controller is actually doing. like literally the only high-frequency diagnostic we have is “listen to it.”
I don’t forsee any changes to wpimath in 2027 beyond leaning harder into immutable APIs over mutable ones. Java’s lack of operator overloading makes many parts of the library much harder to maintain. Here’s the JNIs so far: allwpilib/wpimath/src/main/native/cpp/jni at main · wpilibsuite/allwpilib · GitHub
- The Java versions of Pose3d.exp() and Pose3d.log() had a lot of measurable object allocation overhead, and lack of operator overloading made them unreadable.
- Several linear algebra routines don’t exist in our Java linalg library EJML:
- Matrix exponential
- Matrix power
- LLT rank update
- Full-pivoting householder QR
- Complex eigenvalue solver and column-pivoting householder QR for IsStabilizable() (used for precondition checks of LQR and Kalman filters)
- ArmFeedforward and Ellipse2d use Sleipnir for autodiff and numerical optimization, which is a C++ library.
- The state-space libraries that underpin a lot of the physics sims may end up getting JNIed as well in the future due to lack of readability/maintainability.
Fundamentally, we have to write a maintainable library, and that’s easier to do in C++ due to the math involved and the maintainers we have.
3 Likes
For some types on onboard control, there are options for logging high-frequency data on both REV and CTRE devices (though the latter is only fully accessible to Phoenix Pro users). It’s not necessarily as easy for students to understand as having the code fully accessible, but it’s better than nothing.
3 Likes
As I understand it, the PCM/PH is not required to use a fused channel, but can instead be on a 20A breaker. This can be a good idea as the compressor’s surge current will blow fuses under some circumstances.
The radio and RIO current must be on a (10A) fuse and in practice it is almost unknown for these fuses to blow. If they were to blow a fuse, it would indicate that something is badly wrong, and hence self-resetting might be a bad idea.
The rule-makers therefore have two considerations for the radio and RIO: Maximize reliability and maximize safety. Maximizing the reliability means they want to minimize the points of failure, and hence they may not want to allow the use of a MPM. Maximizing safety may push them to keep the radio and RIO on fuses and thus allow an MPM.
I don’t know which way they’ll go. I think it depends on how strong the desire is to keep the radio and RIO on fuses as opposed to self-resetting breakers.
1 Like
yeah, i think the wpimath stuff is more ok to blackbox, just because the students aren’t experimenting in things like matrix solvers or manifold retraction, they’re using them to explore topics of control.
an example of the sort of thing i would want to preserve would be, say, experimentation with signal conditioning, or transients in control, or implementing unusual controllers (e.g. sliding mode) which means making the whole measure-control-actuate chain available.
We have LinearFilter at least, because the implementation was trivial.
The more exotic controllers I’ve seen use linear algebra, which is precisely what sucks to write in Java. I realize 90% of teams use Java now, but C++ is just better suited for teaching fancy on-robot controls; math is much easier to express in it, math library support is more complete, and on-robot behavior is more deterministic (so controllers are easier to tune in practice). The 2027 MRC will address the third issue for Java, but not the first two.
For off-robot controls learning, Python or Julia are nice because they have the same expressiveness and library support as C++ with faster/easier developer iteration and built-in plotting.
5 Likes
agree, I like python for coprocessors except for the glacial performance and the bad multi threading and the big barrier between python and native code … 