Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MLA-12] update protobuf for vector observations #2862

Merged
merged 21 commits into from
Nov 7, 2019

Conversation

chriselion
Copy link
Contributor

@chriselion chriselion commented Nov 6, 2019

Several changes to the proto objects:

  • Rename CompressedObservation proto message to Observation, and add optional float data
  • Remove AgentInfoProto.stacked_vector_observation. These are now passed in the Observation array
  • Remove BrainParametersProto.vector_observation_size and num_stacked_vector_observations. The former is now inferred from AgentInfos, and the latter is redundant now that StackingSensor handles the stacking.

Includes C# and python changes necessary to support these changes, and updated the existing demonstration files.

var numFloats = sensor.Write(m_WriteAdapter);
var floatObs = new Observation
{
FloatData = new ArraySegment<float>(m_VectorSensorBuffer, floatsWritten, numFloats),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool

@@ -56,4 +56,24 @@ public interface ISensor {
string GetName();
}

public static class ISensorExtensions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is the equivalent of adding code in a header file. Nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just wanted an implementation that used the interface method. https://stackoverflow.com/questions/2770333/can-extension-methods-be-applied-to-interfaces says it's OK.

@@ -523,6 +518,17 @@ public void InitializeSensors()
Debug.Assert(!sensors[i].GetName().Equals(sensors[i + 1].GetName()), "Sensor names must be unique.");
}
#endif
// Create a buffer for writing vector sensor data too
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might need to discuss alternatives to this. We need to have somewhere for non-compressed sensors to write before passing this to the proto objects; this seemed like a good way to prevent repeated allocations. Another option would be to have the Communicator have a cache of Observations (indexed by size), and it manages the Write() calls before converting to proto.

int floatsWritten = 0;
// Generate data for all Sensors
for (var i = 0; i < sensors.Count; i++)
{
var sensor = sensors[i];
if (sensor.GetCompressionType() == SensorCompressionType.None)
{
m_WriteAdapter.SetTarget(m_Info.floatObservations, floatsWritten);
floatsWritten += sensor.Write(m_WriteAdapter);
// only handles 1D
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's currently an assumption that compressed observation <=> 3 dimensional. We should (later) add an option to write visual obs as floats, just to test all the code paths (and maybe a compressed vector obs too).

/// </summary>
/// <param name="sensor"></param>
/// <returns></returns>
public static int ObservationSize(this ISensor sensor)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed this (product of the shape components) in a few places so added it as an extension to ISensor. Any objections?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@surfnerd surfnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:excellent_wayne:

CompressionTypeProto,
from mlagents.envs.communicator_objects.observation_pb2 import (
ObservationProto,
NONE as COMPRESSION_TYPE_NONE,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit awkward, but CompressionTypeProto.NONE doesn't work on protobuf<3.8

Copy link
Contributor

@vincentpierre vincentpierre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The demo files all changed, are we sure they are still working (loading and training)

@@ -8,8 +8,15 @@ enum CompressionTypeProto {
PNG = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe NONE and PNG should be changed to NO_COMPRESSION and PNG_COMPRESSION to avoid the bug you see with NONE ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem isn't with NONE, it looks like it's any enum in protobuf <3.8. See protocolbuffers/protobuf#6028.

That being said, if you think those are better enum names, we can change them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, we can also update the min protobuf version to 3.8.0

@chriselion
Copy link
Contributor Author

I wrote a one-off script to update the demo files. I'll reconfirm that they work though.

@chriselion
Copy link
Contributor Author

For posterity, here's the script https://gist.github.com/chriselion/3714d05255eea2f9132b96a182fbdcaa (it's not generally usable, so not adding to source control)

@chriselion chriselion merged commit 720679a into develop Nov 7, 2019
@delete-merged-branch delete-merged-branch bot deleted the develop-MLA-12-obs-proto branch November 7, 2019 22:58
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 17, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants