Blog Home  Home RSS 2.0 Atom 1.0 CDF  
The Efficient Coder - Robotics
There has got to be a better way of communicating with our computers!
 
 Sunday, March 18, 2007

NiVek J.D.'s Maiden Voyage

Everything came together today for NiVek's J.D.'s official first journey.  NiVek J.D. is a remote control tractor purchased from Target that was converted over to be controlled via a small on-board computer programmed in Java.  The same basic board I used for NiVek I was used for this "robot".

This robot has two cool features not on NiVek I.  The first is it has a GPS module purchased from Parallax.  The second and which I think is really exciting is it using a Windows Mobile device as a "Repeater" that allows for communications from the NiVek embedded computer to a a PC.  This design is based upon software components that are part of WiMo or Windows Mobile Robot, you really need to check out that site!  This consists of some kewl software components that are made up of a Compact Framework 2.0 application that runs on Windows Mobile and a collection of services that run under Microsoft's Robotics Studio.

NiVek J.D.'s Hardware

Basically the radio was just ripped out of the existing remote control tractor and and the motors were connected to the NiVek embedded computer.  As with the "original" WiMo, the Windows Mobile device was mounted on a servo with a CD-ROM.  The original WiMo used a SmartPhone not a Pocket PC so that probably worked out a little better, it's nice to be able to pan the camera however with my driving skills (smacking into walls) one of these days, I'm pretty sure the CD-ROM is going to end up in pieces ;-).  I need to re-think that part of the design.

NiVeK J.D.'s Maiden Voyage (well at least one of the first few)

50,000ft System Overview

  • The actual robot itself is controlled by an embedded computer based upon a small PIC processor with some additional components that allow it to be programmed in Java with 32K RAM & ROM this was purchased from Parallax and is called a Javelin Stamp.  (See this post for more information)
  • The embedded computer has a BlueTooth transceiver module that allows it to communicate with a Windows Mobile Device.
  • The Windows Mobile Device has a Compact Frameworks 2.0 application running code available from the WiMo Bot web site.
  • The Windows Mobile WiMo application communicates with the robot via BlueTooth.  It also has the ability to listen on a socket for connections from a remote application.  Since this is a Windows Mobile device (in my case a phone), it will not only work while it's connected via a local LAN via WiFi, but it can also communicate via the GPRS radio and be a sort of "repeater" that will allow it to communicate to a host controller program anywhere it has cellular reception, just think about this...this is very kewl!  A nice feature is on the opening screen shot of WiMo it tells you the IP address of the device.
  • On the PC side you have a set of Microsoft Robotics Studio services.  When these services first start you will be greeted by a dialog that will allow you to enter the IP address of the remote Windows Mobile device.
  • Once you press "Connect" (and the software gods are shining on you) you should establish a connection from your PC to the WiMo application.
  • At this point a couple of additional forms will show up from the MSRS services.  The one in the upper left is displaying console messages from MSRS (Microsoft Robotics Studio).  This is a great way to see what's actually going on with your services. 
  • The one in the upper right is from a service that came with WiMo (with the addition of buttons to control the motors).  Another really cool built in feature with WiMo is the ability to use the camera on your Windows Mobile device to send pictures back from your robot.  This from also sends messages to the core WiMo communications MSRS service to pass those to the WiMo device application.  These messages allow for control of the robot from the PC.
  • The dialog in the bottom is an additional MSRS service that was built that subscribes the the TextMessageReceived event from the core WiMo service. 
    • The NiVek embedded computer spits out GPS readings every second (probably need to change this so it only sends when the location changes). 
    • This gets sent from NiVek to the the WiMo software on the device with a simple <stx><etx> binary protocol.  The WiMo software turns it into a simple text message. 
    • For our GPS WiMo constructs a simple text message "GPS: #Sats=4 Lat=28.4.042 Long=82.42.5522". 
    • This text message is sent over the wire from the Windows Mobile application to the WimoComm MSRS service. 
    • The WiMo MSRS service picks up the text message and finds any services that subscribe to this type of incoming event.
    • The GPS Point plotter MSRS service subscribes to these messages so it takes those readings and plots the on the crude dialog you see below.  The challenge here is that for a robot this size of NiVek J.D. if it moves 50ft that's a long distance, and the resolution on the GPS module I purchased just doesn't seem to be all that accurate.

Finally one last picture of you host at the controls!

Looks like my day job is going to be busy over the next few weeks with DevConnections and MEDC but I hope to sneak in a few hours every once in a while to push this effort forward!

Can anyone figure out what NiVek stands for?

- ec

3/18/2007 5:29:28 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Hardware | Mobile | Robotics  |  Trackback
 Saturday, February 10, 2007

Microsoft Robotics Studio Communications Protocol

 

Ah – the weekend, time to do a little coding for fun!  One of my on-going projects it to build out the functionality of my latest robot NiVek I.  Although the robot itself has a little computer it doesn’t have much of a user interface, that is provided via a PC.  Therefore for the PC to configure and display the telemetry from the robot a communications channel needs to be established.

There is a cool little card that you can get at Parallax called the Embedded Blue transceiver, this little devices takes TTL (+5v) level signals from a microcontroller and allows for serial communications with another BlueTooth device (such as a computer).  So I can hookup a couple lines on my Javelin Stamp chip to the Embedded Blue device, then establish a BlueTooth connection and it’s just like having a two way serial cable between my computer and the robot, very nice!

 

Now that we have our serial link we need a nice general purpose (and simple) protocol to exchange data.  In a past life I worked on a lot of embedded systems that needed to talk to the outside world.  This is very similar to what I wanted to do with my robot.  Here’s what I came up with.

 

<STX>                        - Start of Transmission Character (0x03)

<LEN_MSB>              - Most Significant Byte of the size of the data packet.

<LEN_LSB>               - Least Significant Byte of the size of the data packet

<DEVICE_TYPE>       - Single byte that identifies the device (Enum type in C#)

<DEVICE_ID>             - Since there may be many of these devices, we have a simple numeric id

<DEVICE_ACTION>    - An additional byte that describes the action (Also an Enum type in C#)

<PAYLOAD>              - An additional set of bytes that represent any data to be passed.

<CHECK_SUM>         - A single byte check sum to validation the message

<ETX>                        - End of Transmission character (0x04)

 

Once we’ve defined this protocol, two chunks of code need to be written on each device that will be “talking”.  We need some simple methods to build up the packets.  We also need a simple state machine that will look at the bytes coming in on the serial port and build up these packets. 

 

On the PC side, a simple state machine was built that progresses through each of the bytes from the serial port, once the ETX is received, an event is fired to pass the message to host that decides how to handle the message.  Creating the new packets to send is even easier, it’s just simply a static method that takes the DeviceType Enum, DeviceId, DeviceAction Enum and Payload and constructs a byte array.  Once complete that byte array is then dropped into a queue to be sent out on the serial port.

 

For my Java robot, our options are fairly limited, the Javelin is a cool little chip however the Java Interpreter is not very complete, no Garbage Collection and no real multi-tasking.  So here I did kind-of a round-robin type of thing where I have a main program loop, then I established the different services such as checking the sensors, checking the in buffer, performing actions etc..  One of those tasks was to check the serial port in buffer for new characters, if new characters are available, they are parsed via a state machine, once a message is complete it's dropped into a queue.  Then when the main loop checks the queue it pulls out the message, and based upon the DeviceType, it just hands the message off to the Java class that handle that device in a nice clean Handle Method.  Sending out a message isn't all that clean but since the Serial UART built into the Javelin chip works in the background it may not be that bad.  Basically each device calls a method on the Communications interface within the program to just dump the bytes into the output buffer that follows the protocol defined above.

 

If anyone is interested in getting a copy of this code, just drop me an email.

 

-ec

 

2/10/2007 7:02:44 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   Robotics | Software Engineering  |  Trackback
 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
 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
Copyright © 2009 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: