Objects are instances, as you describe. As such, you'd need to think about how your class model would be instanced at runtime. It's likely that the instances you have at runtime will vary based on the actual scenarios your software encounters, which is why different object diagrams can vary structurally even if they are all tied back to the same classes.
If you have multiple instances of a class, each instance would be represented using a separate object in UML.
Anything that is abstract in class terms cannot be (by definition) instanced, so you will only have instances of concrete sub-types (e.g. if Scout was abstract).
Even if a class has multiple attributes, only some of those attributes may receive values at runtime, so you may only define a runtime state for your object that is a sub-set of the attributes on a class.
This is an example based on your class model, but depending on the scenario there could be many such incarnations:
