Software Update #9: Beware of Falling Pianos
Before our focus turns too heavily towards offseason activities, I’d like to reminisce a little about our 2022 season…through log data, of course!
Season Statistics
At last, we can look at summary statistics from a full season of play. These statistics are calculated based on all of the data from the robot since it was first powered on (which includes driver practice, auto testing, and real matches). I also thought it would be fun to include a few real world comparisons, some of which are more reasonable than others.
- In total, the robot generated 1051 log files totalling 4.67 GB.
- The code ran 19 million loop cycles, which is about one for every person in New York state.
- The robot drove a total distance of 20.6 miles. That’s 3.6x the height of Mount Everest, or 60x the length of the George R. Brown Convention Center.
- It drove 5.6 miles during matches and 2.5 miles autonomously.
- The robot attempted 5830 shots, equivalent to an average basketball player over 40 games.
- The flywheel rotated almost exactly 1 million times. That’s about 70% the total number of rotations of Big Ben’s hour hand since it was built.
- The hood rotated a total of 121 thousand degrees (336.8 rotations), which means that the flywheel rotated about 3000 times for every hood rotation.
- The intake was actuated 7758 times, which is about one actuation for every two matches of Rapid React played worldwide.
- The total power usage was 8187.9 watt hours. It turns out that energy usage opens the door to lots of fun comparisons. (Thanks WolframAlpha!)
- With that energy, you could drive 32 miles in a normal electric car.
- In Massachusetts, it costs an average of $2.10 to buy the electricity.
- It’s equivalent to the potential energy of a “Medium Grand Piano” dropped from an airplane at cruising altitude.
- …or the kinetic energy of 90 cars at highway speed.
- It’s 50% of the required energy to accelerate 1 kg of matter to escape velocity from the surface of Earth (ignoring the atmosphere).
- You could generate the energy by burning a little less than a quart of gasoline.
We can also compare data across events. Here’s a breakdown of a few statistics — all of these are measured per match.
Here are a few of my observations from these graphs:
- The number of loop cycles is noticeably higher on Einstein than any other event, because the robot tended to be on the field for longer before the start of each match (the whole log file is included in the analysis).
- Across all of these statistics, our most “aggressive” matches tended to be at Greater Boston rather than the Championship; we drove farther, shot more balls, rotated the flywheel farther, actuated the intake more, and used more power. There are probably a lot of factors contributing to that (including both driver practice and software changes), but it’s definitely an unexpected result. This isn’t necessarily a negative either; maybe it’s a sign that our matches at the Championship tended to be more efficient and streamlined?
- The difference in the average distance driven on Roebling vs. Einstein is less than a foot (0.18%). I’d like to think this is a sign of our consistent and reliable drive strategy, but it’s probably just a coincidence…
- Our average shot attempts per match more than doubled from Granite State to Greater Boston. We certainly performed better at Greater Boston, but that change is definitely larger than I would have predicted.
- Similarly, our intake actuations increased from Granite State to Greater Boston by a factor of 6. This one is no mystery though; we started automatically retracting the intake at Greater Boston to avoid penalties. That relatively minor change is made much more dramatic when visualized like this.
The detailed log data from each of our events is available here:
Zebra Analysis
The Zebra data from our Einstein matches provides some interesting insight into the accuracy of our on-field odometry. Below is an example from one of our matches. The solid robot represents our on-field odometry, and the translucent robot represents the Zebra data (corrected based on the robot’s rotation).
Over the course of the match, here’s the distance between the on-field odometry and Zebra data in meters (the orange rectangles indicate that the robot was shooting):
This looks pretty good at first glance — the error is under one meter for most of the match. When running this analysis, I arbitrarily chose to start with match 8. Here’s a summary of the odometry error for all of our Einstein matches:
This paints a more…sobering picture of our accuracy. In matches 12 and 15, the target tracking was very unreliable. For example, here’s the corner data from a particularly problematic frame in match 12:
We’re not sure about the cause of this extra noise, given that it doesn’t appear (to a significant degree) in any of our prior matches on Einstein or Roebling. It’s possible that we were just a little unlucky with the reflections in those final matches.
But it’s not all bad news! We really only care about the accuracy of the odometry when we’re actively shooting, which is also when the Limelight is pointed towards the target. Our median odometry error while shooting is 47 cm, which is more than accurate enough to reliably make shots.
We also prepared for the possibility of odometry errors like this. Using the override switches on our operator console, the drive team was able to fall back on shooter presets for any matches where the odometry was inaccurate. This allowed the robot to stay in operation despite lowering our ceiling a bit.
When not shooting, our choice of WCD + no turret definitely makes it more challenging to maintain accurate odometry throughout the match. I’d be very curious to compare our results to any teams running with swerve and/or a turret.
We’ll continue to post updates as we start work on offseason projects. As always, we’re happy to answer any questions.
-Jonah
