search

BYU-PCCL / holodeck

High Fidelity Simulator for Reinforcement Learning and Robotics Research.
https://holodeck.cs.byu.edu
MIT License
574 stars 42 forks source link

Add OSX Support #221

Open jaydenmilne opened 5 years ago

jaydenmilne commented 5 years ago

Josh did some initial investigations, and it wasn't hard to get Holodeck running on OSX. We should look into porting Holodeck to OSX and providing binaries for it.

jaydenmilne commented 5 years ago

So it seems OSX support is going to be a lot bigger of a pain than we thought.

The APIs around shared memory and semaphores is similar, but subtly different than Linux. Most of them we can work around, but the tricky one is the 30 character name size limit on semaphore/shared memory names.

Even without a GUID and shortening the prefix of the names considerably, we can still go over that limit with things like '/HLDK_MEM_uav0_RGBCamera_sensor_data'’. To make matters worse, those names are user defined, so if a user gave a really long name like UnmannedAerialVehicle0 or gave a sensor a long name in a config file it would fall over and die on OSX, which doesn't make for a very good user experience.

We would either have to (in order of difficulty):

  1. Use short names in config files and only allow one instance of Holodeck at once, and pray we never go over the limit

    This would mean you couldn't use Holodeck for serious training on OSX, only for debugging or developing. This might be acceptable.

  2. Rework the naming scheme

    We could have some back and forth communication between the engine and the client to negotiate names, since 30 characters really is plenty of entropy. We would have to have a way for the client and engine to agree something like /H1924829_A953 corresponds to '/HLDK_MEM_uav0_RGBCamera_sensor_data'’

  3. Use something other than POSIX shared memory and semaphores on MacOS

    Apple encourages OSX developers to use something other than POSIX, we could look into that and see if we could make wrappers around those APIs

jaydenmilne commented 5 years ago

Thinking about it, I thin our best bet is to

  1. Calculate what the the sensor name would be, ie /asdk3-zUUID-HLDK_MEM_uav0_RGBCamera_sensor_data
  2. Hash that string (ie MD5, SHA-1/256)
  3. Truncate the string to 25 characters or so
  4. Use the truncated string as the memory / semaphore name

The chances of having a collision are very slim, would still allow users to use whatever names they wanted, and would allow multiple copies at once.