Add software device python #4269
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
June 23, 2019 09:55
The API methods for rs2_software_sensor_add_*_stream can return an error in various cases. In the old implementation, the returned error code was not checked before sending the result to the `stream_profile` constructor. This was causing the originating error to get swallowed and made debugging the actual problem harder. This fixes this method so that the first error is reported and not subsequent errors.
This adds a new private method for software_sensor for searching for profiles by UID. This also makes this code more readable.
The cached value of the `_default` flag was causing problems with the ability to set the default profile flag on the software device's sensor profiles.
Issue IntelRealSense#4197 This adds the ability for the user with access to the `software_device` and `software_sensor` classes to configure and set the `camera_info`, `option`, and stream profile parameters. This allows for serial number, name, etc to be written and configured. This also expands the `software_device` to accept an explicit context argument.
Issue IntelRealSense#4197 This commit adds a new group of devices in the backend for emulated devices. I tried to find a way to make the `playback` devices operate like emulated devices, but I couldn't find a way that wouldn't break existing funcionality. I ended up adding a separate emulated devices group that gets treated similar to hardware devices when used with the `pipeline` and other context configurations.
Issue IntelRealSense#4197 This commit adds new interfaces to the python wrapper to support emulated realsense devices for testing. The emulated device can be define completely in python. Allows for image publishing. The motion (accel/gyro) is untested. I've only replicated a D435i due to hardware availability limits. Emulated Device is operable with the `pipeline` and config construction.
|
Hi @callendorph |
Merged
|
Hi @callendorph |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
This PR is targeting issue #4197. This PR is not a merge candidate - I'm trying to get feedback about direction only.
I've implement the functionality that allows me to emulate a D435i device on a
rs2.contextobject. I can create a pipeline object and pass in a configuration that targets the emulated device by serial number. I can subsequently interrogate for camera_info, options, and grab frames. All of these settings are configured through the API. Here is an example python session where I create a trivial emulated device.Keep in mind, that my goal here was to get something functional - not to have the end all, be all, perfect solution and API. I've also not added unit tests yet because I want to make sure that the direction I'm heading is reasonable before investing time and energy into that.
I've primarily attempted to add this functionality by adding to the API only - not modifying it. There are very clearly ways that we could make the API for the software device more concise if we changed the signature of certain methods. For example,
rs2_software_sensor_add_writable_optionandrs2_software_sensor_add_read_only_optionare redundantly and could probably be combined into a single method with areadonlyargument. Are you accepting of this kind of consolidation of the software device API or would you prefer to have maximum backward compatibility?The current implementation adds a new
emulateddevice backend because I didn't want to break functionality related to theplaybackdevices. I would appreciate any feedback on this approach and how it integrates with the rest of the project. Specifically, in thecontextobject I have added a vector of emulated devices, and this has caused thecontext::create_devicesandcontext::on_device_changemethod signatures to expand and become rather ugly. I could integrate this into theplatform::backend_device_groupobject but I wasn't sure because theplaybackdevices are stored separately from this group object. Thoughts?I did not see any unit tests for the python wrapper. Do you have a preferred platform for python unit tests if I were to try and add some ?