In a bit of a learning experiment, I’ve implemented a new feature on this site: The Mailing List. You can now subscribe for email notifications in the top right of the website, or at the bottom of every post!
Current limiting is a fantastic tool in the hands of the engineer - it allows us to keep power demands under control. But is there a better way to control the power demands of our actuators, to make them more controllable? Could we limit acceleration and torque, too? Can we stop our robot from tipping, before it happens?
In all the buzz of build season, it’s common that we forget what we’re meant to be teaching. In terms of programming and coding skills, well-structured programs and good practice are often foregone in favour of unstructured spaghetti designed to ‘just get the robot moving’. In this post, we’ll be talking about how to structure our code for flexibility, reliability, and how to solve the “mechanical team isn’t ready yet” dependency problem.
2018 was a great season for OpenRIO. On our main project, GradleRIO, there have been 251 teams and 1427 unique users from 7 countries, with 52.9 thousand total builds since January 1st, 2018. Let’s take a deeper look at the numbers…
Earlier today, I did a talk for FRC Team ARTEMIS on Computer Vision, demonstrating the basics but also diving into some advance topics. Here, I’ve released the slide deck, video and some further reading materials.
Recently posted on The Blue Alliance blog was a fantastic post by Eugene, outlining the math behind OPRs through the use of the Least Squares approximation to solve an overdetermined system of equations. In this post, I’ll be going over the specifics of the normal equation and give an understanding of how it works.
Alternative Title: Jaci you’re not allowed to play with Assembly anymore.
Motion profiling has been making the rounds lately, with more and more applications for it, including Automation, Self-Driving Vehicles, and pretty much anything that moves with a computer. A while ago I wrote the Pathfinder library, which was designed for 2D S-Curve trajectory generation, in short, a path planner. Today I’m going to combine that with a post I wrote a few weeks ago on making Vision Processing more efficient.
You can see the project on GitHub here
TL;DR: We can run 30fps Vision Tracking on the RoboRIO at 7-8ms per frame, equating to only about 23% CPU Time. For scale, the FRC Network Comms program uses about 20% CPU constantly
When I wrote Toast for Java, I had a master plan for the simulation environment, and it had to fit the following agenda:
- It has to work with the official FRC Driver Station
- It has to work when the Driver Station is on a different computer
- It has to be easy to use
- It can’t have external dependencies outside of the bundled software.