none
MRDS open sourcing RRS feed

  • Question

  • Dear MRDS team,

    Rumours (http://spectrum.ieee.org/automaton/robotics/robotics-software/microsoft-shuts-down-its-robotics-group) say you exist no more. And that is somewhat better than the utter silence before because it provides us with at least some certainty. Nevertheless, I and probably some other MRDS customers are still here and alive. And the bugs have also decided to stay with nobody to take care of them.

    My question is if there is any chance of MRDS going open source? If even .Net Framework has done it...

    Thank you.

    Wednesday, November 19, 2014 6:16 AM

All replies

  • I would love to see this happen, too. It seems like a great way to keep MRDS alive. It would also address the concerns of many robotics programmers who compare MRDS to ROS and prefer ROS's open source nature.

    It seems to me that parallelism features in recent .NET framework versions may render the CCR obsolete. DSS still seems valuable, though. The two are coupled via the ServicePort attribute, so it's hard to use DSS without CCR. If MRDS were open sourced, we could at least try this idea.

    I've been struggling a lot recently trying to decide which way to go with future robots: ROS or MRDS. I love using the higher level language and constructs in MRDS, but right now it looks like a dead end. We need a way to move it forward !

    Wednesday, November 19, 2014 9:01 PM
  • Is there any one alive in Microsoft? 

    They just left the room!

    Wednesday, December 3, 2014 12:18 PM
  • No wonder. In their shoes I would probably do the same. Look, there are only two replies. Only three men of the entire community are interested in MRDS open sourcing. Would you bother even thinking about it in this situation?
    Thursday, December 4, 2014 9:50 AM
  • I've said it before and will continue to repeat it.

    There is no reason to start a robot project today with MRDS. Everything it had has now been built in to .Net.

    As said above, 'parallelism features in recent .NET framework' make CCR obsolete.

    WCF replace DSS and took it to a higher even more useful place.

    MicroFramework is supported on Netduinos, and Gadeteers, and IS open source so you can roll you own if you wish.

    Visual programing died, RIP.  The simulator, realistically needed a lot of work. 

    ROS is a bigger step back in time. An OS designed around teletype machines, with early concepts that have never been able to modernize because of legacy issues.  MS did the right thing, move on.

    Just use .Net.

    http://www.spiked3.com
    PC/Windows based robotics

    Saturday, December 6, 2014 1:56 AM
  • I can't agree with you entirely.

    DSS is not only narrow technology which could be replaced by WCF. It is also implemented infrastructure and tools and higher levels ideas.

    The simulator needs work, and this was my point, but it, as is, is much better than no simulator at all, isn't it?

    And what about not starting a robotics project but continuing existing one? I don't feel like moving all my code to some other technology.

    Sunday, December 7, 2014 12:13 PM
  • >> implemented infrastructure and tools and higher levels ideas

    I think DSS service partners is a good example of this. WCF doesn't offer a feature like that. CCR arbiters is another example of an MRDS feature that does not exist in modern native .NET.

    I think that any 'missing' features like that could be developed in modern .NET. I sympathize with Matvey's concerns about moving code to a new technology, but it's clear to me that we're not going to get any help from Microsoft. 

    Monday, December 8, 2014 6:22 AM
  • I just read all about .Net Core (http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx). It's MS's new, open source, direction for the .Net Framework. Very interesting stuff.

    Microsoft, please, please, please extend this new "open-ness" to MRDS. Particularly the simulator !

    Wednesday, January 14, 2015 5:49 PM
  • Matvey and Cogswell have some valid points; especially regarding the DSS partnering and the CCR arbiters.  Unfortunately, MS has abandoned MRDS.  Not all hope is lost though... 

    I've been able to replicate the DSS partnering functionality using only CCR.  Furthermore, I've been able to replicate a good portion of CCR using TPL, thus presenting an option of applying some great concepts/patterns without the dependency of MRDS.  Would be happy to discuss...

    I have not had the opportunity to replicate the "remote node" capability of DSS via WCF.  Would be happy to discuss...

    Hoping the pioneering efforts entrusted to the MRDS technology stack will not whither in vain...


    Dennis M. Knippel

    Wednesday, January 14, 2015 10:20 PM
    Moderator
  • Cogswell, I could conjecture, that we are next in the line after Silverlight) The article is great, thank you.

    Dennis, I wonder, why have you been doing it?

    Friday, January 16, 2015 4:12 PM
  • Matvey,

    I've been pursuing RDS solutions since 2007.  I've always been impressed with its parallelized nature and its partnering architecture.  It's a refreshing contrast to the HelloWorld cesspool of sequential programming mentality and/or self-righteous zealots nervously guarding their legacy C++ apps.  Admittedly though, the VPL and Simulation components of the RDS suite have always been lacking.

    Regardless, using CCR/DSS have yielded some great software solutions to my clients such as Systron Donner Automotive, FIAlab Instruments, SRS Medical, The Boeing Group, and Agilent Technologies.

    However, the fate of RDS has been written on the wall for some time now and so I've made efforts to migrate the CCR/DSS functionality to a more agnostic C# .NET framework.  It's called NOMAD Origins.  Basically, it's the same path that Spiked3 suggested.  One particular manifestation of NOMAD Origins is called NOMAD City which is basically a "lights-out" manufacturing platform with an underlying goal of integrating CAD design directly into the automated fabrication process.

    As with all "frameworks", NOMAD Origins is an ever evolving work in progress.  But, I think with a bit more polishing it can serve as a life buoy for existing software dependent upon RDS, as well as new software that wants to exploit the coordination primitives of CCR along with the distributed nature of DSS.

    Just standing on the shoulders of giants for now... :-)


    Dennis M. Knippel

    Friday, January 16, 2015 5:39 PM
    Moderator
  • I've been able to replicate a good portion of CCR using TPL, thus presenting an option of applying some great concepts/patterns without the dependency of MRDS.  Would be happy to discuss...


    Dennis M. Knippel

         I would be very interested in your efforts to replicate CCR. I have a rules engine that I need to port to TPL/TPD.

    Thursday, February 5, 2015 7:43 PM
  • Hi Steve,

    I'm currently on a project in Burbank, CA for eSolar.  I'm available during the evenings/weekends to chat.  Perhaps a skype session sometime?  Would you be able to tell me a bit more about your solution or perhaps direct me to a website to get a feel for the context in which you've applied CCR?

    Thanks,


    Dennis M. Knippel

    Thursday, February 5, 2015 9:00 PM
    Moderator
  • Sure, I can tell you more about my solution, I will put some thoughts together and get back to you.

    It's not being sold as a product so there isn't a website to give any background info.

    It's an in-house medical fraud rules engine that is the basis for the company that I work for.

    My predecessor chose CCR/DSS back in 2010 when as you know there wasn't a lot of options for building concurrent applications. Now that Microsoft has shut down it's Robotic arm, I have decided that I better start looking for a way to replace my use of CCR.

    I am a little old school and don't have a web cam so chat would have to suffice. 


    Friday, February 6, 2015 1:44 AM
  • Hi Steve,

    I'm pretty old school too -->a chat would be fine.  Please email me at dknippel@wiesenportz.com and we can setup a day-n-time to talk either by phone/Skype.

    BTW, is this an in-house product that Verisk Health uses?  Also, does the current tool use both CCR & DSS or just CCR alone?

    Regards,


    Dennis M. Knippel

    Friday, February 6, 2015 2:42 AM
    Moderator
  • Dennis, your work on NOMAD sounds very interesting. I've been pondering an open source .NET Robotics Framework that would replace RDS. Is NOMAD a candidate for the start of that ?

    I thought about contributing to the ROS.NET project instead of trying to make something new. The only advantage of that is that you could communicate with other ROS nodes. All the great ROS tools still wouldn't run under .NET.

    To all the posters on this thread: Is there sufficient impetus to start a Google group to discuss an RDS follow-on or replacement ?


    • Edited by CogswellCogs Monday, February 9, 2015 6:17 PM typo
    Monday, February 9, 2015 4:41 PM
  • Hey guys, I just now re-looked at this conversation. I guess somewhere along the way I turned of reply notifies and did not know there was any.

    I finally made the leap this week of actually understanding ROS. It is usually so dependency broken I give up, but I guess my timing was lucky and I actually made it through installation to see a running project. What I saw pretty much confirmed what I had thought about it. I did a lot more digging, and indeed saw that the ROS team is looking at 2.0 for breaking changes and a complete update to ROS architecture. Like MRDS also needed it will replace internal infrastructure with industry standard accepted practices (eg off the shelf message broker).

    Anyhow I started playing with my own light ROS /MRDS like structure. I am still thinking the actual robotic part is almost 0 code. Instead it would be more of a guideline to using existing tech (eg MQTT and JSON). The part that is needed is accompanying tools and modules.   http://www.spiked3.com/?p=4211

    This is the second time I have heard that the arbitrator can not be replaced by native WCF. I've used both ROS and MRDS, but have always used more of a simple LeJOS type behavior/arbitrator pattern (loosely based on http://www.amazon.com/Robot-Programming-Practical-Behavior-Based-Robotics/dp/0071427783/ref=sr_1_1?ie=UTF8&qid=1423726795&sr=8-1&keywords=robotic+behaviors ). Is that not enough? 

    Anyhow, I would be happy to host any framework you need (ie web/discussion/forums), or help in any other way if you get something going with a common goal on the subject of ROS / MRDS replacement.

    Thursday, February 12, 2015 7:48 AM
  • I'm nearly ready to run my new ROV for the R/C Tank Combat group (http://www.rctankcombat.com/). The hull is almost done, and I'll switch off to the operating software before building the turret. So, I need to use SOMETHING. ROS was a mixed bag for me. Like Spiked3, I found those dependency issues, too. I like Gazebo and the ROS data visualizers, but everything seemed like a step back in time.

    I guess I'll cook up something new. If you'd like to host a discussion, I can certainly try to incorporate the ideas we come up with. I agree that there shouldn't be a lot robot-specific code. One of the first issues I wrestle with is the need for different message types. For example, I'll need:

    1) A fast, low-latency, connectionless, unreliable transport for high volume sensor or MJPEG video data. I was thinking native UDP for this, maybe even using IpV6 multi-cast.

    2) A reliable transport for sending commands. I'd also need an option to receive a response back from the receiver.

    I'd like to hear some community ideas on these topics.

     Thanks,

    CogswellCogs


    Monday, February 16, 2015 8:30 PM
  • MQTT (and MQTT-SN) have various quality of service levels. My understanding is that some provide for ACK and some do not. What I have read though seems to indicate on lower power implementations, like an Arduino, the ACK'ed version is not implemented.  I have not dug that deep into it, yet, but I too am at a point where I need to.

    I've run into a few 'challenges' to work around. MQTT-SN adds sequence numbers and CRC to messages to assist in their delivery over unreliable comms (wireless).  What I have seen is even for wired comms, the Arduino serial is unreliable as it poorly handles UART data tying it to interrupt pins that might otherwise be used, and so you need to take extra steps.  I would prefer to implement MQTT-SN but it has no Windows support I can find. Brokers depend on Unix socat implementations, and Windows versions of socat are several years old and abandoned. Thus I did my own little serial/MQTT bridge, which is still being worked on. (http://www.spiked3.com/?p=3391)

    I had a friend set up a topic for us to discuss more if you wish. I'll start by reposting the last couple of messages from here.

    http://synergyhub.org/forum/modern-robotics-framework-(mrf)/

    You will have to go through normal sign up stuff. I am told after a couple of posts the captcha goes away. Let me know if you have any problems, spiked3@gmail.com

    Tuesday, February 17, 2015 1:57 AM