FAQ

What’s the difference between DogLog and other logging libraries?

Within the FRC software ecosystem, there are three main solutions for logging: DogLog, AdvantageKit, and Epilogue.

Here’s a quick breakdown of the differences between each library:

	DogLog	AdvantageKit	Epilogue
Creator	Team 581	Team 6328	WPILib
Logging pattern	DogLog.log()	IO interfaces and annotations	Annotations
Use case	Simplest logging possible	Replaying logs in simulation	Log every public or private field in a class
Customizable log destinations	Yes (NT and datalog)	Yes (NT and datalog)	No (NT always on, datalog can be toggled)
Multithreading	Fully configurable (can use main thread or a separate thread)	Required (always uses log processing thread)	No
Tunable values	Yes	Yes	No
Unit metadata	Yes	Yes	No
Supported language	Java	Java	Java

While it may technically be possible to use DogLog in combination with other logging libraries, this is definitely not recommended. You will almost certainly encounter bugs or other compatibility issues as a result.

Who uses DogLog?

DogLog is used by teams across the FRC community for a variety of purposes. Here’s a selection of DogLog users with open-source robot code you can review for inspiration:

• Team 4522 - Team SCREAM, extends DogLog to support logging fields at different frequencies to minimize loop times
• Team 3847 - Spectrum, uses their Telemetry class to seamlessly integrate priority levels, Command logging, etc., with DogLog’s extensible API
• Team 9496 - LYNK, breaks down triggers for high-level logic by logging their main robot state with DogLog

And of course,

• Team 581 - Blazing Bulldogs, uses DogLog to provide visibility into robot automation, accelerating development at home and improving reliability at competitions

What should I log?

It can be tempting to simply throw every possible piece of data at DogLog, but often times this causes more problems than it solves. While DogLog is highly optimized for performant logging, at a certain point the roboRIO simply can’t keep up with the volume of data being logged.

Take a look at all the fields you are logging, and think about whether or not they’re actually useful for your team. Here’s a few examples:

• Several debug logs added when first doing robot bring-up, which aren’t relevant anymore
• Logging more values than necessary for every motor (ex. temperature, stator current, supply current, applied voltage, velocity, etc.)
• Capturing all NetworkTables values, instead of just manually logging the handful of relevant fields

How can I get help with DogLog?

Feel free to open a GitHub issue if you’ve found a bug or there’s a feature request you’d like to see.

If you have questions about DogLog, how to use it, or anything else, you can start a GitHub discussion or create a reply on the DogLog Chief Delphi thread.

Why use imperative logging?

Imperative logging describes the pattern of calling a function to log a value. Compared to alternative methods like IO layers or annotations, imperative logging is the simplest approach.

You have full explicit control over what is logged and when, compared to annotation based logging. Annotation based logging typically involves using Java’s reflection to discover all the fields in a class, and then schedule logic that records all the fields to a log file.

Imperative logging avoids the complexity associated with reflection, you just call DogLog.log() and the value gets logged. Rather than the sort of “magic” that reflection uses, DogLog prioritizes clarity and simplicity.

How does DogLog work internally?

DogLog itself is a fairly minimal library, all the actual logging is handled by WPILib using DataLogManager and NetworkTables 4. This ensures that DogLog takes advantage of the stability and performance of WPILib’s logging system.

Rather than trying to reinvent core logging primitives, DogLog focuses on providing a clean, powerful API on top of the WPILib logging featureset, without introducing extra complexity.