Jonathan Mayer

We've been hard at work here on a simulator for the Urban Challenge. It's based on our own vehicle dynamics model and simulation engine (no slight intended at the MSRS group's much more advanced and significantly more robust simulator), and works quite well thanks to MSRS's proxy system. We build "dummy" services that model actuator response instead of controlling actuators, as well as provide dynamically generated sensor data, but leave the proxy the same. Our navigation and path following algorithms don't even require recompilation to switch between simulation and the real world!

The problem we're running into is adding other vehicles to the simulator. It'd be plenty sufficient for the time being to implement other vehicles with the same behaviors as our own vehicle's, but we're not sure what the right way to accomplish that would be in MSRS. Our vehicle essentially consists of a "stack" of services - at the highest level is sensor input, then comes path planning, and finally actuation. What'd be ideal is some way of creating services in groups - i.e. a "Vehicle" consists of all the services that are required, and the individual services that make up a "Vehicle" could each be addressed. Is there any way of guaranteeing which instance of a service you'll be talking to

The best approach we've come up with so far is to use a DSS node for each vehicle. While it would work, it'd be rather annoying to coordinate and add a bunch of overhead. Is there a more reasonable approach that we're overlooking

Thanks,
Jonathan



Re: Microsoft Robotics - Community Dedicated Partnered Services

George Chrysanthakopoulos

I may be misunderstanding, but couldnt you write one "loader" service per vehicle type, where it programmatically starts and configures all services for that vehicle That service can send Create requests to the Dss constructor service, then send Replace/Updates to each service to configure parameters, etc. The initial state for that "vehidle service loader" service can contain vehicle specific info.

multiple such "loader" services can exist per node.





Re: Microsoft Robotics - Community Dedicated Partnered Services

Jonathan Mayer

That sounds like an excellent solution! What I'm unclear on is how to ensure the proper partnering between services. Using Create to generate the required set of services for each "Vehicle" seems straightforward enough, but what would be the right way to make sure the proper instances of each service are pointed at each other Would Replacing/Updating the port for the partnered service be sufficient Perhaps using a ServiceForwarder to the desired instance of the specific service





Re: Microsoft Robotics - Community Dedicated Partnered Services

George Chrysanthakopoulos

I believe i have given some examples in these forums, on how you can use the programmic Create request, specify a list of partners (and fill in the URIs for example) and thus ensure that the service you are creating, has a list of partners it needs, on start.

Our manifest loader service is another alternative that does most of the work for you: Create a ManifestType instance, send it as an Insert request to the ManifestLoader of each node, and in the manifest instance, give some names to the service records, *** partners using those names, and we will do the cross-service hookup.

To summarize, if you go the code route, there are two options:

1) In some "vehicle creator" service, write the code that creates the services in the right order, fills in CeateRequests with the right partners (and service URIs for dependent services), and sends the Create operation the service constructor of each node/PC

2) Again in some dedicated service, create a manifest instance, in code, and send that to ManifestLoader. That is a more higher level approach that re-uses our code.

this thread should probably move to the DSS subforum, its very DSS-centric Smile