Blog Home  Home RSS 2.0 Atom 1.0 CDF  
The Efficient Coder - Monday, January 29, 2007
There has got to be a better way of communicating with our computers!
 
 Monday, January 29, 2007

NiVek 1

Over the weekend I finally had a few hours to get all the basic functionality working on my latest robot "NiVek I"

I'll be doing some additional posts along with some source code, but below are some of the cool features

Hardware

  • Traxster Chassis and Turret from Robotics Connection
  • Main Board and Turret boards I designed and had manufactured by PCB Express based upon the Parallax Javelin Stamp a PIC processor with additional RAM/ROM that has a built in Java Interpreter
  • Bluetooth Communications via Embedded Blue transceiver
  • I2C bus driven by the Javelin Stamp
  • GPIO14 General Purpose IO A/D & D/A on the I2C bus
  • SD20 20 port Servo Control on the I2C bus
  • 3 Sharp GP2D120 IR Sensors mounted on the turret
  • 2 Ultrasonic sensors one mounted on the turret and another mounted on a servo to allow panning at the rear of the robot
  • Speech via Daventech SP03 Text to Speech Synthesizer on the I2C bus
  • CMPS03 Daventech Compass
  • Optical Wheel Encoders
  • MotorMindB DC Motor Speed Controller
  • 2 laser pointers mounted on the turret for range detection (this will be a great post once I work out the details)
  • GrandTec Wireless Web Cam mounted on the turret
  • 2 x MC24LC256 256K I2C Serial CMOS EEPROM

Software

  • Software on robot written in Java
  • Simple <STX><ETX> communications protocol with Device Type, Device ID, Device Action and Payload along with a Check Sum communicating from the robot to a C# application via BlueTooth
  • Although the first version of the controller application is a C# Win Forms application the Communications Library is setup to create Microsoft Robotics Studio Services (when time permits)
  • The following features are controlled via the existing console
    • Motion Detection Algorithm on Web Cam Input
    • Drawing heading on web cam input
    • White half moon displays ranges from three IR Sensors on turret
    • Turret Pan & Tilt controlled via sliders
    • RGB Display used for turning laser detection algorithm (range finding)
    • Motor Controls via slider
    • Speech Control

There just aren't enough hours in the day to do all this fun stuff!

- ec

1/29/2007 9:12:00 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Robotics  |  Trackback
 Saturday, January 27, 2007

Backup Strategy with PowerShell and ntbackup

About once a year, I spend about a day going doing preventative maintenance on my development servers.  Today is that day.  I've had basic backups being done via a scheduled task an NTBACKUP, these seem to work, but luckily I've never needed them.  What I didn't like was that although my SQL Server backups send me emails I look for each morning, my file backups didn't.  I did a little research on some programs out there, anything that I would trust for this kind of stuff seemed rather expensive so I decided that I could take this opportunity to learn Windows PowerShell and create my own little backup strategy...disclaimer, although this process seems solid, in no-way-shape-or-form will Software Logistics be liable if you attempt to mimic this process and for some reason you may loose data.  If you continue on reading, we'll just assume that you'll accept this disclaimer and won't try to take my house if something goes wrong!

Here's my setup...

  1. I have a Windows 2003 R2 Server acting as my Virtual Machine Host, off of this machine I have a decent 200GB USB 2.0 Hard Drive.
  2. Download Windows PowerShell 1.0
  3. I've downloaded the program that helped write my scripts PowerShell IDE there might be something a little better, but this seems to work.
  4. I already had the backups setup on my SQL & Exchange servers, so on those boxes I created a network share called \Backups.
  5. Now on my USB Hard Drive I created two directories:
    • J:\BackupJobs
    • J:\Backups
  6. In the J:\BackupJobs directory I created my Power Shell File J:\BackupJobs\ProcessBackups.ps1
  7. Then I started to create my script...this really isn't intended as a PowerShell tutorial, but you should be able to get enough out of this to complete your scripts, but basically it does the following:
    1. Create a new Time & Date Stamp directory like J:\Backup\01272007, this will be stored into a variable called "$BackupPath"
    2. Create a variable called "$Body" that will be used to hold the log file for all activities, this will be written to disk with the script
      • $body | Out-File -FilePath $logFile
    3. Create a Variable that holds the individual file name like
      • $UserBackupFileName = $BackupPath + "\UserData.bkf"
    4. Now start my backup process
      • ntbackup backup "\\sl1\users /J "User Data Backup Job" /f $UserBackupFileName | out-null
    5. The piping (|) into the out-null will make sure that the process (ntbackup) completes before moving on to the next step.
    6. Once this completes, I write an entry into the log file with the files names and Paths as well as the completion time.
    7. I then just complete steps 3-6 for the rest of the directories to be backed up.
    8. After everything is backed up, I want to do a little cleanup, here's the process there:
      • Create a new variable called $OldBackup based upon the current date $OldBackup = Get-Date
      • Add -5 days to that via $OldBackup = $OldBackup.AddDays(-5)
      • Now create the Path $OldBackupPath = "J:\Backups\" + $OldBackup.ToString("MMddyyyy")
      • Now we just make sure it exists if([System.IO.Directory]::Exists($OldBackupPath))
      • And if so just blow it away! [System.IO.Directory]::Delete($OldBackupPath,$TRUE)
    9. Once I do all of this I just send my self an email with log data, something like:
      1. $mailServer = New-Object "System.Net.Mail.SmtpClient"
        $mailServer.Host = "MyMail.Server.Com"
        $mailServer.Port = 25
        $msg =
        New-Object "System.Net.Mail.MailMessage"
        $msg.To.Add("BackupAdmin@MyCompany.com")
        $msg.
        From = "Backup.Service@MyCompany.net"
        $msg.Subject = "Backup Completed"
        $msg.Body = $body
        $mailServer.
        Send($msg)

And now my backup is completed!

This was really my first in-depth powershell experience and it wasn't too painful, I'm sure there is plenty of room for optimization but hey it's Saturday and this seems to work!

-ec

1/27/2007 1:46:46 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
 Friday, January 26, 2007

Does this only happen to me?

I've been cruising along on all eight cylinders, making sure and steady progress on a chunk of code.  I get to the point where I think I've got all the problems solved and want to integrate a bunch of things together and whammo - I get a flat tire...something stupid like my VPN drops, a real slooooowww connection speed where it's painful to do anything or maybe a reference to some library "just" disappears, or my favorite something like "Internal Compiler Error please start Visual Studio".  Just as I was ready to pull all the "stuff" together on a project I'm working on today that "flat tire" was all of a sudden my clip board in Vista stopped working...very odd...very frustrating...real momentum killer...

-ec

1/26/2007 11:36:02 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering  |  Trackback

Filtering a SQL Server Table by content of XML

One of my applications parses custom forms from a web site that are defined by an end user, it then stores the actual content of the form as an XML document in a SQL 2005 database.  I recently had the need to write some queries to identify specific records in this table based upon content entered on the form.  To do this I needed a "where" clause that would filter the the records based upon the content of the XML.  The following solution seems to do the trick:

select FormId
  from MyForms
where FormType = 'MyNewForm'
   and FormXml.value('if( /root/Field1=200 eq true() ) then 1 else 0 ', 'bit') = 1
   and FormXml.value('if( /root/Field2=300 eq true() ) then 1 else 0 ', 'bit') = 1
   and FormXml.value('if( /root/Field3=500 eq true() ) then 1 else 0 ', 'bit') = 1

Since our filter arguments (200,300,500) are really passed into and built as part of the string we really can't use a parameterized query, but I think that is probably OK.  Since the initial output of the XQuery is XML, we need to convert that to a "bit" field that we can then use to complete our Where Clause

 -ec

1/26/2007 9:42:26 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering  |  Trackback
 Sunday, December 31, 2006

New class of computing devices UMPC

 

While I was at DevConnections last November, I was introduced to a new class of computing devices, these are called “Ultra Mobile Personal Computers” or UMPC for short.  In my ever humble opinion, these are going to play a huge role in the evolution of the mobile workforce.  Over the New Years weekend, I added to my inventory of computers and purchased a Samsung Q1, although the device came with Windows XP tablet edition on it I was assured by the Employee at an electronics store; whose initials are the same as a type of not very deadly toy gun I had growing up; that all the drivers are available for Vista, I give him about a 50/50 change of being accurate ;)

 

Currently I’m using an HP TC1100 tablet PC and I just love it, some people like the convertible type of tablets that are both a tablet and a notebook computer, however in most cases when I’m using my notebook, I want a fairly high-end machine and when I want a table I want something really portable to do things like capture notes or manage my emails.  A notebook is just really overkill and too clunky.  My first tablet was a Toshiba convertible, I picked it up the first day a Tablet PC was every made available in a retail store.  I liked it because it had a 14” screen and a keyboard, I guess my experience may have been tainted in that after about the first six months a one inch portion of the screen went dead, but I just never really liked this as a table, the screen was just too big and had to always position it to use it in the best way for taking notes.  In addition even though Beth is still using this today, it just really seemed fragile.

 

So why am I excited about the UMPC?  Well I guess mainly its size.  I have considerable experience in the mobile space with PDA’s, but depending on the application/usage, a PDA isn't always the best solution for any sophisticated conversation with your computer.  The tablet or I guess the word for what I like is “slate” without a keyboard is a good solution; however in most cases, you don't need all the real-estate and for mobile the smaller the better.  In addition UMPC’s are to have a price point between $400-$700 which really makes them attractive to users that may not want to drop the $1200-$1500 on a slate or convertible.

 

-ec

12/31/2006 7:34:24 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Hardware  |  Trackback
 Friday, December 22, 2006

Back in Business Again (4 monitor configuration on Vista)

Over the past year, I've really been addicted to using my four monitor configuration within Windows XP.  In October, I made the switch to Vista for my main desktop system and have had a difficulty running in this configuration.  First with a couple of ATI X1300 cards, where when I go into 4 monitor mode, one of the screens was half black half green (with RC2, but not fixed in RTM Vista) Then I purchased a couple of NVidia cards, a 7900GS PCI Express card, and an FX 5200 PCI card, I was able to get these working, however I wasn't able to rotate the screen into portrait mode, which is really almost a requirement unless you want to constantly be tweaking your neck to view all the monitors.  The native drivers for NVidia (at least version 9.6.8.5 dated 10/9/2006) did not support any mechanism for doing rotation so I found this very kewl program called iRotate from an excellent company EnTech Taiwan. The following post describes how to tweak your registry to allow for iRotate to work with the NVidia driver.  They have another very cool program called PowerStrip that allows you to do some pretty amazing things with your video card.

Here's a picture of my development workstation...

The most important part of this setup is just to the left of my keyboard (coffee mug).

I think that 4 monitors is actually an excellent environment for doing development, let me explain my setup

From left to right:
1) 900x1440 Monitor - This is really my system dash board, I run Outlook, keep my IM window open, SysInternals (or I guess Microsoft's) Process Explorer and while really "getting into it" I may start an instance of DebugView or CEDebug view on top of those windows.

2) 900x1440 Monitor - Tool windows for VS.NET, I usually have the following configuration, the screen divided from left to right in about 2/3 on the left and 1/3 on the right, the left side is divided just about in 1/2 with the top having the Output and Error List window, the bottom has properties and a couple of cool VS.NET addins I created using the DevExpress DXCore product (if you have any interest in building add-ins for VS.NET you MUST look at this Free, yes I said Free product, it takes care of all the plumbing so you can focus on your task at hand), one addin allows me to bill time and the other has a bunch of metrics like how much time I've spent on classes, methods, billed against clients as well as the number of builds I've performed.  The right side of the screen has my solution explorer from the top to bottom so I can quickly open files.  In my attempt to free myself from using the mouse, I've started to use hot keys to open files, but the jury is still out on if this is more efficient than just using the mouse.  In addition there is a tab on the right side that allows for access to the Team Foundation Server explorer.

3) 1200x1600 Monitor - This is where the "magic" happens, this is my current port between me and the computer for translating the designs I got from my brain into what ever language I'm using (mostly C#)...still think there is a better way to do this, but that's another post for another day...

4) 1200x1600 Monitor - Work space, this is where I test the application I'm working on, open up IE windows, open up file explorer etc..

The idea with this configuration is really to allow for very efficient context switching, it's much easier to turn my head, then open a window, check it out and get back to my main task

Other "stuff" in the pictures:

I just love my Microsoft Natural Ergonomic Keyboard 4000, it took a little while to get used to but I started without the detachable support on the front that raises the front up about 2" and moved to that after about a week.  I wish it was wireless and had a finger print reader built it, but I've got two of these and feel that I'm at a disadvantage when I can use it.  This is really a good tool to increase the "TX Baud Rate" between the brain and the computer.

I'm impressed with the Logitech mouse line, I had one of the rechargeable ones, but many a time I've been feverously working on a project, the low battery light came on and I didn't have time to recharge before it went dead.  I'm currently using the Logitech MX610 Laser Cordless mouse and like it.  It has a number of feature I don't use, but I like the way if fits in my palm and the battery life is excellent (besides when the battery gets low I just need to grab a couple AA's from my battery drawer and I can continue on with life (instead of get my old corded mouse out while my other one recharges).

 

PDA Collection

My old workhorse (very powerful processor & lots or memory) the HP iPAQ hx2750


My current phone (jury is still out on this one) the Motorola Q (Smart phone not Pocket PC phone)

And finally my i-mate JasJar, I like this device, in my line of work (not a mobile user) it just isn't a good fit.  I use this for testing VGA resolution applications on mobile devices.

And finally you can see my tablet PC hp TC1100 to the right of the monitors in the first pix, I love this tablet, it's a pure tablet, not a laptop wannabee/tablet wannabee, when I want a laptop, I'm usually using it for something completely different than when I want my tablet.  To my wifes joy, I think I'm going to be upgrading to a UMPC as soon as the right one comes out and she get's the coveted tablet.

 

- ec

12/22/2006 10:43:42 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering  |  Trackback
 Monday, December 04, 2006

Flexible Systems Integration Architecture

I may have a couple of large projects next year where I need to build up a great deal of functionality that easily needs to be integrated with existing systems.  What we want is some sort of clean very usable portal concept where a user can work with a predefined set of business objects.  The idea here is not to create some sort of "holy-grail" of a development environment where a business analyst can sit down and drag a few objects on to a page and wire them up.  So now that we took the whole "build a system without one line of code" marketing statement out of our vocabulary we can safely say we do need to write code and figure out the best way to do this to:

  1. Get a high-level of reuse among different implementations
  2. Do programming at the right level to minimize defects tedious coding
  3. React to changes very quickly
  4. Provide a clear upgrade path

First let's define the three aspect that are present in pretty much every system we are going to build, probably in the order of importance and from the most static to the most dynamic:

Data - In each problem domain there are a core set of data that describe the "world" of the domain.  For a sales system, this is going to be something like Customers, Products, Sales People, Sales Orders, Invoices etc...each of these has their unique set of attributes that describe them.  I would venture to say that in most sales system you are going to have at a minimum the above set of objects with probably 85% of the attributes on those objects remaining consistent.  For these type of objects the definition of these attributes probably remains fairly constant with respect to time.  That is to say the description of the objects is probably the most "static" part of your system.  I guess this is pretty much the premise of OO.

Business Rules - Objects by them selves might be interesting however to do anything with them you need to implement some sort of business logic, something like a sales person "CREATES" the order etc...these are really the functional requirements of your system.  In our sales system, although the objects and their attributes are probably about 85% the same across different systems, the actual functional requirements and business rules are probably much less consistent.

User Interface - Well now we have our data in our objects and we have methods so we can make them do something interesting, unless we are building a batch processing system, we need some sort of user interface.  If we look at this in terms of our sales system, there are really three components of our User Interface: 1) Simple CRUD stuff (Create Read Update Delete) 2) The buttons you press to make it do something like create a new order 3) Work flow.  The first two items are really pretty basic, get data from the business object display it on the screen, validate it and dump it back to the biz object as well as react to a button to launch a screen.  The third item is what really differentiates one system from the next, the work flow that's wires up the user interface to the business rules.

Let's talk a little bit about some concepts to solve these problems with a high-level of reuse and integration into back end systems.

Data - As we defined above, we will want to create some sort of rich object model based upon the domains we are building the system for, these should contain the attributes the core attributes that we defined above that are similar between different implementations.  These objects would then in turn be "bound" to the underlying data objects to provide the basic CRUD functionality.  This would either be through the use of implementing interface contracts in a high-level language or creating stored procedures in the underlying database that would bind our objects to the data.  We might implement our Customer object to execute a stored procedure on an Oracle database and return some sort of result set for one implementation and write code to execute a Web Service method call to retrieve the customers attributes in another, either way we let the specific implementation provide the data and bind it to the attributes on the business object.  Our objects would also need to provide some sort of mechanisms return lists and collections that are implemented based upon the data assets within the organization.  The idea here is the business object in our object model provides a well defined set of services to the work flow and user interface layers, but the actual persistence of the data will be implementation specific.

Business Rules - OK now we have a way to load and persists business objects as well as return collections and lists of these.  Now we need to make them do something.  The "do-something" part really comes in two flavors, simple methods we can invoke to set status and send out notifications to more complex work flow with respect to time.  They are tied together, but it may help to think of them separately.  As with our data implementation, our core implementation needs to provide a key set of methods that do certain things, like create a new order, send an email etc...these should be customizable by inheriting form base class and overriding methods.  The next flavor having to do with behavior of the object over time is really considered work flow and this probably the area where now two systems will be a like.  I think the right way to do this is through some sort of Work Flow engine and it just so happens with .NET 3.0 Microsoft released one.  The exciting part of this (at least as far as I understand it so far) we should be able to create our objects that have our properties and methods, but then "wire" them up using XAML to make them behave in a custom way.  This is not say we can build our systems without writing any code, but it does mean we may be able to "wire-up" our apps to get 80% of the way there, and then be very flexible with respect to change over time.

User Interface - I believe that some sort of portal concept is the right way to go here, I'm very intrigued by Share Point Portal Services 7.0 as providing the plumbing to hold everything.  This area probably will require the most customization however this will probably just be starting out with some control templates, dragging a few additional controls on to the template then wiring those controls up to the business objects.  The portal "needs" to be built as a set of building blocks that can be assembled and "connected" at run time.  I think the right way to do this is through the use of Web Parts in ASP.NET 2.0.  In addition, it will be important to create some sort of role based security that controls access to the UI components/data not only to show/hide features and UI components, but also something to secure access to either groups of records or specific records.  It's also important to build and integration story that will leverage any existing credentials that the company may already have.  I would love to see the use of "Card Spaces" for this, but I'm not sure that's all that good of an idea.  This may however be on implementation of our security model.

More to come on this topic...I'm just starting to get my head into these efforts....

- ec

12/4/2006 6:42:18 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Software Engineering  |  Trackback
 Sunday, December 03, 2006

Microsoft Robotics Studio - Very KEWL!

This weekend I'm working at the "beach-house" (well our 28ft travel trailer parked at a campground right one the Gulf at Fort Myers Beach).  Since I've got most of my work deliverables caught up (I hate saying that since I know I'll jinx myself), this weekend I wanted to play a little.  From about 1991 to 1995 my job was to design hardware then write the software that ran on it to make the lights come up in the right order (well maybe make it do a little more than that).  I really loved this but since about 1995, I've been focused mainly on business applications...really a different world.  About once a year I try to spend a few days doing something hardware related so those brain cells don't totally die off.  A few years ago it was hacking an X-Box, then the last couple years it was working on W3, my home-brew robot based upon the BasicStamp chip that contained Sonar, Compass, X-10 Camera and an interface via WiFi on an old iPaq, this was a lot of fun but most of the effort here was actually constructing the hardware and writing the device interfaces.

That brings me to this years effort and MDEC (incredibly good conference) earlier this year I was introduced to the MS Microframework, they had a "Sumobot" competition, unfortunately at the time I was doing the conference in the day and "work-stuff" at night so I didn't get involved.  After browsing the MSDN site last week, I came across the Microsoft Robotics Studio, then saw that it supported the new Lego NXT robotics system...I had to have one of these.  It arrived on my doorstep Thursday and I was set for my weekend in Fort Myers Beach.  I spent Saturday "playing" with lego's and built up the robot you can see between my two monitors.

Next was to get it talking to the computer, this was actually pretty easy since the NXT has built in Bluetooth and the communications "stuff" happened in the plumbing of the MS Robotics Studio.  My prior solution was to hookup an RS232 serial port between my BasicStamp chip to the inputs on an iPAQ, then I used the WiFi card in the sleeve to do some lo-level socket stuff to talk to the desktop app.  This is much cleaner!

So now all the pieces are in place, I've got the robot setup, I've got communications up and running, now it's time to make it do something!  We have three little terriers in our trailer that don't like being left alone.  My goal is to hookup the sound detector on the robot to fire off an SMS message to my cell phone when the dogs start barking (so we don't get kicked out of anymore RV parks).  Then I want to allow some sort of PocketIE interface to manipulate the robot to take "correct actions", I think I should be able to hookup my software to my MCE that is in the trailer, then with some Text-to-Speech stuff, issue the "No-Bark" command to the pups and see how that works.  There is also a small wireless web cam I plan to get for this...I think that would be extremely interesting

-ec

12/3/2006 11:03:50 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1]   Robotics  |  Trackback
 Saturday, December 02, 2006

Morse Code Reader

I was really brought back in time after reading the following post.  When I was a in junior high, I was I guess what you call a "early adopter" to being geek.  I got my HAM radio license and purchased a Heath Kit SB100 radio (Vacuum tubes and all).  I learned Morse code to get my license but was happy when I could interpret Morse Code at 13 words per minute and got my general class license and could actually use a microphone to talk to other folks.  In the mean time, I read an article in a Popular Electronics magazine that talked about how to build a circuit to digitize the tones from the speaker "playing" the code (using a Schmidt trigger if I remember right).  I was on my second computer after saving up enough to get a VIC-20 (after my Timex Sinclair) so I built a little chunk of code to convert the tones to actual characters on the display, this worked well!  The other chunk of functionality I needed was the ability to key the transmitter to send out code, I think I used a bit on the joystick port to drive a relay and I was set.  This brings me back to the original post from Ashish Derhgawen, he wrote an output from a parallel port on his PC to drive an LED (I didn't see the current limiting resister in his screen shot, but maybe this is one of those new fangled LEDS with it built in).  He had a challenge on the bottom of hist post to identify what the message he was sending, I had a difficult time reading the Morse code from the LED, so I had to write a little program to read the LED and turn it into dots and dashes I could easily read...I'm not going to give away the answer to his challenge, but if you know Morse code it should be obvious.  I wouldn't call this a very robust solution, but sometimes coding is just fun.

Anyway here is a screen capture of the simple program...

The SWF file just gets loaded up into an IE component on the form, then here's the snippet that reads the LED, the rest is a simple state machine...

-ec

12/2/2006 11:10:17 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]    |  Trackback
Copyright © 2012 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: