With over 10,000 teams across the globe, the VEX Robotics Competition (VRC) is the world’s largest high school robotics program. Combining engineering and strategy, VRC challenges students to build and program robots for game-based tasks. For the past three years, Daniel Alp has competed in VRC as the captain of his school’s team. They’ve made it to the world championship twice and were finalists in the 2024 Ontario, Canada provincials. 

Software plays a key role in VRC, often being the factor that differentiates a good robot from a great one. As Daniel puts it, “automation is where most of the complex problems in robotics are found—localization, path planning, and motion control to name a few—but being able to move faster and more precisely than your competitors is well worth the effort it takes. That said, you can’t just throw advanced algorithms at your robot and expect it to zip around the field. To squeeze every bit of performance, you need to tune your robot’s movements, and this is usually a long and frustrating process”.

Initial Attempts at Tuning 

At first, Daniel’s team tried simply watching their robots move and using that as feedback, but they quickly realized that this approach was insufficient. “While our eyes caught some details, we were missing many others, and so it was impossible to gauge progress past a certain point”. 

To improve, the team started logging sensor readings and motor commands to an SD card, then reviewing the data in Google Sheets. This helped with fine-tuning and catching bugs, but was far from perfect: importing data was slow, visualization options were limited, and organizing the data became increasingly difficult. Daniel and the team were limited to just line and scatter plots. “What we really needed was a way to visualize the robot’s pose as a path on top of the game field—this would be extremely useful for testing localization and inspecting issues during autonomous routes”.

Given that their previous visualization methods were lacking but writing a tool from scratch would’ve been impractical, Daniel sought a solution that offered both out-of-the-box visualization and extensibility. Enter Foxglove! 

Using Foxglove

“For one, sending custom data to Foxglove in real time was straightforward” says Daniel, “simply host a WebSocket server and implement Foxglove’s subprotocol”. Foxglove’s pub/sub messaging decouples it from your data source, allowing you to focus on just advertising topics and sending messages. Libraries for writing these servers are also provided, abstracting away the protocol and exposing a simple API. The real challenge was communicating with VEX. “In short” as Daniel explains, “I had to reverse-engineer VEX’s protocol and develop a bridge between Foxglove and VEX. At a high-level, the robot streams data by writing messages to its stdout, which the bridge then fetches, processes, and relays to Foxglove. As a bonus, the bridge also writes these messages to MCAP files, which can then be imported into Foxglove for playback”.

Daniel was also able to further leverage Foxglove’s extensibility to write a custom panel using the Foxglove SDK. “I found the API documentation quite comprehensive, and the examples repository as well as the public extension registry also provided useful reference points”.

After setting everything up, the team quickly assembled a chassis and got to programming it. The chassis was equipped with shaft encoders and an IMU, which were used for localization and motion control. Turning in place was done using a PID controller, and moving in a straight line involved following a velocity profile with a feedforward-feedback controller. By leveraging Foxglove in their workflow, Daniel’s team was able to greatly accelerate development. “Foxglove made diagnosing hardware and software problems much faster, helped us pick up on subtler issues, and streamlined tuning the robot’s movements”.

Conclusion

“Overall, I’ve found Foxglove easy to plug into and customize. Instead of sticking with inefficient visualization methods or getting bogged down in reinventing the wheel, I was able to move quickly and significantly cut the time spent tuning and debugging”. 

For a detailed account of how the Foxglove-VEX bridge and VEX-2D Panel were implemented, as well as the challenges faced, check out this technical blog post on Daniel’s website. “And of course, give Foxglove a try—it’s working out quite well for me!” says Daniel.