Microsoft Robotics group?

by Mike Linnen 20. June 2006 10:25
Microsoft Robotics group?

Wow, did you know that Microsoft has a robotics group?  I just noticed that they released a Microsoft Robotics Studio.  I am downloading this technical preview now to check it out.  This to me is a huge leap for the robotics industry.  Putting the power of Microsoft development tools to build robotic applications is a win win solution.  I finally can merge my two passions of software development with Microsoft technologies and building robots!  I am very excited about this project.  Make sure you check out the Channel 9 video about the group.  Keep an eye open for your favorite robot somewhere in the background of the video.

Some projects the group is working on.

Key features of the platform

  • Concurrency and Coordination Runtime (CCR) - An asynchronous messaging library that makes managing state changes easy to the developer.
  • Robotic remote control via a web browser
  • Scripting robotic commands via jscript to create complex robot movements
  • Multiple hardware platforms.  Currently supporting Lego Mindstorms (RSX and NXT) and fischertechnik.
  • Support for 8, 16 and 32 bit processors
  • Separating state from behavior
  • DSS - A services layer
    • Support for service contract programming where multiple input or output devices can be used by simply altering what device is bound to the contract.  Example:  A contract could be established that controls the robots movement.  A keyboard device could be bound to the contract to provide the input that moves the robot.  Or a joystick device could be bound to the contract to provide the input to move the robot.  The point here is that support is in place for a pluggable architecture or re-usable components.
  • Subscribe publish model that allows for a lot of autonomous agents to react to state changes.  This promotes a decoupled environment.  You can create a published event like bumper touched and later build a component that subscribes to that event and reacts to it.  There can be multiple subscribers to the event. 
  • Model simulation - You can model your environment and run your software without any hardware.
  • Since the applications are service based you could distribute services across multiple machines. 
    • Example if I create a service that monitors my door bell and expose the service to the public you could subscribe to my service and perform some action when my door bell is rung.

Well I could go on and on about this new platform but I want to get started on using it.  I will first go through the tutorials to gain an understanding of how it works.  Luckly I have a Lego Mindstorms RSX kit.  After the tutorials are complete I will try extending the services to support a BX24 bassed hardware device.

Interfacing a PC to the outside world Part 2

by Mike Linnen 24. November 2005 20:26
Interfacing a PC to the outside world Part 2

In Interfacing a PC to the outside world Part 1 I mentioned that I wanted to work on a set of articles to discuss interfacing your PC to the outside world.  In part 2 I am going to continue the series and talk about what my first connection to the outside world is going to be. 

 

There are a number of devices that are designed to communicate over I2C.  I2C is a serial interface developed in the 1980's at Phillips Semiconductor.  The architecture allows for multiple devices to co-exist on the same 2 wire bus.  You can get more information on the I2C bus at the following: http://www.esacademy.com/faq/i2c/. 

 

There are a considerable number of devices that support the I2C bus.  A compass can be used to determine direction.  A sonar module can be used to detect obstacles.  A motor controller can be used to drive motors on a robot.  A servo controller to drive hobby servo motors.  All of these I2C capable devices (and several more) can be found at www.acroname.com.  I have done some research on PC I2C devices but so far everything I have found is fairly expensive.  I believe I can make a device that will bridge the PC to I2C gap and open up the world of I2C devices to PCs.

 

So a .Net I2C library is going to be the first project that I will do.  The library will support communicating on the I2C bus to other devices.  The consumers of this library should not care how the I2C communication is actually implemented.  So the primary goal of this exercise is to architect a provider model for communicating to these devices.  The benefits of this model allows for different I2C providers to be used without affecting the consumers. 

 

The first provider I will be creating will be a micro controller RS232 I2C Provider.  This will be  a small device that sits between the PC and the I2C devices.  The micro-controller's job is to intercept the serial commands from the PC and convert them into I2C commands.  I will be using a BX24 from Netmedia as this micro controller.  Later I will create a parallel port I2C provider that can be used in place of the micro controller RS232 provider.

 

The PC to BX24 I2C solution is a little more expensive than I intended to start with.  However I have a few BX24s lying around from other projects so it won't take a dent out of my pocket.  Also I have a Deventech compass to try the library out on.  Besides I also intend to use the BX24 for other interfacing projects.

 

    

Tags: , , ,

Robotics

Interfacing a PC to the outside world Part 1

by Mike Linnen 23. November 2005 10:15
Interfacing a PC to the outside world Part 1
 

I have been reading some of the Coding4Fun articles that are on MSDN.  Several of the articles are focused on connecting your computer up to external devices and writing .Net code to interface with the devices.  This has always been a main interest of mine since I am interested in robotics and home automation.  The resent release of .Net 2.0 has made some nice features available for doing serial communications.  Also Microsoft has made the Visual Studio Express editions freely available for 1 year.  This makes up a great solution for the general hobbyist to play with software and hardware.  So I thought it was time that I start my own set of articles on building software and integrating it to hardware devices.

 

So I gave it some thought on where to begin.  What project will be a prime candidate?  How would I build the foundation so I could leverage different hardware solutions to a given interface problem.  So I decided on a few goals to keep in mind about the project:

  • Provide a solution to an interfacing problem that could be used in many projects.
  • Build the library using .Net 2.0.
  • The library should extract the consumer from any hardware implementation.
  • The library should be testable without hardware implementation. 
  • The library can use external pluggable components to fulfill the interface to the hardware itself.  So 3rd party components can be built and plugged into the library.

 

Stay tuned for a series of articles on this project

Tags: , ,

Robotics

.Net 2.0 Serial Port

by Mike Linnen 19. November 2005 17:53
.Net 2.0 Serial Port

Hey looks like the new .Net 2.0 supports a serial class that makes serial communications a snap.

http://msmvps.com/coad/archive/2005/03/23/39466.aspx

I need to get going on some project to try this out.  Maybe a PC to BX24 project that will be useful in my house.  I need to give it some thought. 

Another Test example for the BX24

by Mike Linnen 20. October 2005 01:25
Another Test example for the BX24

A previous post I explained how simple it is to test your code even though you might not have a fancy test framework like NUnit.  In this post I am going to give another example of what I did to tackle a robot navigation problem and fully testing it without actually running the code in a real robot.  My point here is that it is a good practice to write test code to test sub modules to simulate all possible scenarios that would be tough to do in the real robot.

So here is the problem:

I have a compass module that outputs a heading value that equates to 0-359 degrees. I needed a module that when given a target heading and a current heading it could return the differance between the two in degrees. The return heading difference would range from -180 to 180 degrees. This return value could be processed further to determine which direction the robot needed to turn to reach the target heading. A negative heading ment to turn left and a positive number would mean turn right.

So my approach was to first identify a list of target and current headings and what I would expect the return value would be for these input parameters. I did this for 17 different scenarios. I placed the values in a spread sheet and analyzed the pattern that emerged. I took this pattern and coded a simple class (module) that would impliment the pattern.

Here is the method of the class:

Public Function GetHeadingDifference(currentHeading as Integer) As Integer
  ' Returns the following
  ' -180 to + 180
  ' Negative number means the robot would have to turn to the left to get closer 
  ' to the targetHeading
  ' Uses module variable targetHeading
  
  Dim targetMinusCurrent as Integer
  targetMinusCurrent = targetHeading - currentHeading
  
  If (targetMinusCurrent<181) And (targetMinusCurrent>-181) Then
    GetHeadingDifference=targetMinusCurrent
    Exit Function
  End If
  
  If (targetMinusCurrent<-180) Then
    GetHeadingDifference=360 - ABS(targetMinusCurrent)
    Exit Function
  End If
    GetHeadingDifference=(360-ABS(targetMinusCurrent)) * (-1)
End Function

I then created another test class (module) that would call the navigation module and pass in the 17 scenarios and validate the return heading.

Public Sub Main()
  '.......... Test code ..........
  'This needs to be done only once per program, or when you want to change the baud
  Call UARTsetup(3, 19200)  
  InitializeNavigation
  Dim testResult as Integer
  Dim newHeading as Integer
  Dim targetHeading as Integer
  Dim currentHeading as Integer
  
  '****************************************
  'Test TestHeading
  '****************************************
  DebugPrintLine "TestHeading Tests"
  newHeading=180
  currentHeading=180
  SetTargetHeading newHeading
  testResult=TestHeading(currentHeading)
  If (testResult<>0) Then
    DebugPrintLine "Test 1 Failed"
  Else
    DebugPrintLine "Test 1 Passed"
  End If
  newHeading=180
  currentHeading=183
  SetTargetHeading newHeading
  testResult=TestHeading(currentHeading)
  If (testResult<>-1) Then
    DebugPrintLine "Test 2 Failed"
  Else
    DebugPrintLine "Test 2 Passed"
  End If
........... more test code omitted for clarity 
End Sub 

I used the 17 scenaros that I layed out on the spread sheet to prove out my logic. Since the module is fully tested based on these scenarios I have complete confidence that the module will work when it is included in the main robot code project.

Testing without a testing framework

by Mike Linnen 19. May 2005 06:53
Testing without a testing framework

I have been doing a lot of Unit Testing in my day job using NUnit as the framework. I find writing code to test code is very interesting and makes my coding efforts less bug prone. However in my off time I often mess around with non .Net programming projects and I miss the ability to write test code in these projects. Well it is not too hard to follow the same sort of unit testing practices when you do not have a testing framework in place.

Just recently I was writing some BX24 code for a robotic project. I needed to create some conversion procedures to go from a Byte/Integer to a String and a String to a Byte/Integer. How would I determine that my new procedures would work as designed? Certainly I could not rely on the production robot code to test the conversion procedure.

The BX24 programming language has the concept of projects and source modules. A project is nothing more than a collection of source modules. One of the source modules must be the main entry point of the project for starting execution. This concept allows me to simply create test projects that are designed to test a single source module.

So I moved my conversion procedures into a Conversion Module and made a Conversion Test project. Then I proceeded to write test code in the main module of the Conversion Test project to exercise the Conversion Module. I now had unit tests that exercised the outer bounds of the Conversion Module. I proceeded to fix bugs in the Conversion Module until all tests passed.

Of course without a framework I did not have the nice GUI with Red/Green lights to tell me a test passed or failed but it sure did help me determine if my module was fully functional or not. So if you have a programming project that does not have a nice unit testing harness but your IDE supports module level programming you to can use the above techniques to write bug free code.

Tags: ,

Robotics

.Net Hardware Projects

by Mike Linnen 11. April 2005 15:24
.Net Hardware Projects
Looks like Scott Hanselman is gearing up for some .Net Hardware related articles. Some of his brainstorming ideas are similar to my Home Automation Ideas. Like the use of X10 and a Video Monitor for the front door (Although I see I never documented the Video idea on my wiki). Maybe I can leverage some of the ideas Scott is going to write about.

Although his Lego Robot idea may not be Home Automation specific it sure comes close to the project I did with the ER1 robot from Evolution Robotics a couple years ago. I used C# to extend the capabilities of this wonderful robot.

I think I should break my project into more manageable sub-projects just to get something going. My Home Automation project is not getting off the ground so far. At least I documented a few ideas so I can get back to it.

Tags:

Robotics

Articles I wrote on robotics

by Mike Linnen 28. February 2004 08:19
Articles I wrote on robotics

A while back I wrote some small articles on robotics for the local Hobby Robotics Web Page

Building a Maze Robot - How I built a maze robot to win a robotic competition in Phoenix Arizona

30 Days of ER1 - Details about using the ER1 robot from Evolution Robotics for 30 days.

These guys used some of my Vector 2X code I published a long time ago in their class project

 

Tags:

Robotics

New Walking Robot soon to be sold

by Mike Linnen 26. February 2004 00:04
New Walking Robot soon to be sold

Mark Tilden has designed a new toy robot that uses some real cool features.  The power consumption technologies alone are worth the price of the toy.  It uses the motor to assist in generated power to charge the batteries.  The end result is a robot that can run continously for 20 hours!  That is impresive!  Check out some video clips on the robot.

 

Tags:

Robotics

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List