Protosystem Blog

By

 

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

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. 

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.