DARPA Urban Challenge
Here at Princeton University we are using MSRS as the backbone for our system to make a car (in our case, a Ford Escape) drive itself through a city. Our efforts are part of the 2007 DARPA Urban Challenge, a Pentagon-sponsored race for autonomous vehicles that will take place in November(
http://www.darpa.mil/grandchallenge).We have written and rely upon over 25 MSRS services running across 5 dual-core servers. Many of these services are for a lot of commonly used robotics tools like a Roboteq Motor Controller or a LabJack ethernet DAQ device. With some cleaning up we'll probably be in a good position to share these services with the wider community.
To get a sense of the kind of work we've done in the past and what we're doing right now, check out our websitehttp://pave.princeton.edu (we also have some cool video clips available athttp://pave.princeton.edu/main/media and an overview of our use of MSRS athttp://pave.princeton.edu/main/urban-challenge/msrs). Expect to see a copy of our tech report for this project on our site within the next week or so.
Feel free to contact us with comments, suggestions, encouragement, or whatever (preferably not spam
) atpave@princeton.edu
josh
Josh,
I was at the last DGC's site in Primm, and I have a great admiration for all teams that got there, especially because I'm working on a similar, small scale project.
My platform is a gasoline ATV and we have at least two things in common, I'm seriously thinking about using msrs in this project and we are using roboteq motor controllers.
If you are serious about sharing your services, I'd be more than happy to use it. That would be the utmost test for loose couplingness...
By the way, I'm with San Diego State University's Intelligent Machines and Systems lab.
Cheers and good luck!
Very Impressive work, It's a strong indication that MSRS will eventually rule as an industry standard for robotics. But until that happens I am very curious regarding how your team is managing to write an obviously very complex application while lacking thorough & comprehensive documentation for MSRS ?, What are you doing really ?
My own experience with MSRS is very tough so far, trying to figure out on my own how to make things work properly, asking for information on the forums, not getting any response some times.
Regards
Salah
One thing that took us a while to realize is that many components in MSRS are documented elsewhere. Iterators and yield return, and DataContract/DataMember are documented in other places. For example, if you Google (or I guess Live search) for 'iterators yield return' you'll get tons of useful hits. You'll have to be willing to watch a lot of videos to get a handle on the CCR. Here's our list of links we use:
For arbiters, ports, concurrency ( the CCR part of the runtime):
A good introduction:
A video 'deep dive' into the CCR API. Also has a bit about writing a TCP client in MSRS in the comments following:
another video demo from George:
an academic-style paper on the ccr (a bit out of date--the concepts are right, the function names are not):
For distributed services and messages:
The messages are serialized using approximately the same ideas as the Windows Communication Foundation (WCF) which is documented here. Let me reiterate that MSRS's serialization is not the same as WCF's. These links can only give you an approximate idea of how MSRS works and I have no idea how close the two really are:
On defining a data contract ([DataContract] and [DataMember] stuff):
On serializing collections (not sure how accurate this is):
Data types supported (this may not be very accurate. Dictionaries didn't serialize in MSRS 1.0. However, 1.5 allows serialization of dictionaries and lists of lists.):
DSS protocol definition:
DSS patterns (eg, messages):