System.IO.Ports.SerialPort Work Around

I’m adapting NiVek to communicate with my Windows 8 machine via a serial port…sorry no serial port support yet in Windows Store apps

As I’m doing development, I’m constantly rebooting NiVek which drops and recreates the USB virtual serial port.  When it does this, the port configuration on my machine gets “messed” up and I need to do the right sequence to restart communications.  If you’re reading this far, you probably know what I mean.

Reading the “IsOpen” property on the SerialPort instance doesn’t reliable say the port went away, I’m not going to get into whether it should or shouldn’t…it doesn’t and is the cards we’ve been dealt.  So the only way to know your port is closed is attempt to send something, if it throws an exception, well, you know it’s been closed…no comment.

Here was my original code:

Once an exception is thrown, one would think you would want to close/dispose of the serial port instance, however it throws an exception.  Note: Not sure if a using statement would make a difference, however the my current architecture that really wasn’t an option.

Enter the registry:

This will let you know the ports on your machine.

What I found was that when the exception was thrown, the serial port disappeared from the Device Manager, but it still remained in the registry while my program continued to run.  This was an important clue.  Then the next time the USB virtual serial port connected, it was already in the registry but some how was invalid…again…no real clue what happened under the hood there, all I know is if my app was running and attempting to reconnect to the newly connected serial port, but since the old registry entry never went away something didn’t go right to register the serial port and make it available to my app.

Remember from my code snippet above, when the exception was thrown, calling _nivek.Dispose() generated another exception?

By sheer accident I was stepping through the code, executed _nivek.Dispose(), an exception was thrown, but I refreshed my registry and wammo…COM7 was no longer there!

Apparently prior to Dispose() blowing up, it did enough cleanup to removed the closed COM port from the registry.

So changing my code to this piece of "art” *cough* *cough*…

…removed the COM port from the registry, handled the exception and the next time I connected my virtual serial port, the connection immediately opened.

Please feel free to comment if you have a better solution, I had to hold my nose while I wrote this, but it get’s me back to the important stuff.

enjoy!

-twb

NiVek QC Update

This project is very much alive, it just turned out to be one of the bigger efforts I’ve ever worked on and my “day-job” has been busier then ever.  I hope to post some very good news shortly as my flight tests are looking more an more promising, but wanted to do a quick post on some fairly significant discoveries I’ve made over the past few weeks:

Telemetry/Communications

One of the primary goals of NiVek QC is to fly it with either a standard RC controller or through a Windows 8/Windows Phone app, this makes the telemetry and communication channel performance critical In my first generation of software I was using TCP/IP over sockets.  This was using these little WiFly RN-XV 171 serial to WiFi adapters in a XBee form factor https://www.sparkfun.com/products/10822.  It didn’t happen very often but every once in a while the connection dropped.  Obviously this isn’t a good thing. 

In my next generation I switch over to just a wireless modem using a 3DR telemetry kit http://store.3drobotics.com/products/3dr-radio-telemetry-kit-915-mhz.  This solved my connectivity problems but at a much lower transmission rate (57.6K) as well as introduced a certain level of corrupt messages.  My telemetry protocol uses CRC checking to handle corrupt messages but this really isn’t desirable.  A nice thing about these radio modems is their claimed range of 1KM.

Finally I arrived at using UDP over those WiFly adapters in the first generation.  Since the UDP is connectionless, there is no connection to drop.  I do have some watchdogs in the firmware however that if we don’t get a heartbeat at a predefined interval we assume something bad has happened and kill the motors…side note, I need to rethink this since yesterday during flight testing I was flying at about 30 feet and NiVek was a little down range, telemetry dropped and the crash wasn’t pretty.  Another nice feature about the WiFly 4.0+ firmware is that it can now behave as an access point which makes connecting much easier.  In infrastructure mode, the WiFly will attempt to “auto-response” to the first connection it receives via UDP but I’m having some challenges with this.

PID Controller – D Component

From my testing, I’m seeing that this is probably the most important component for flying a quad.  By it’s very nature the quad is unstable and it’s really a fly-by-wire control method.  The firmware is responsible for taking inputs from the Gyro/Accelerometer, figure out the current attitude and rate of change of that attitude of the copter then apply correction factors to the motors.  I had a bug in my previous D calculation so once I worked through that issue, stability improved greatly.  I’ll provide more details in a future post but the idea is that the D calculation correction factor takes into account how quickly the quad is rotating on the pitch and roll axis and attempt to smooth this out.  With my gyro’s sampling at 700 times a second, the accelerometer sampling at 400 times a second and the control loop running at 200 times a second it seems like I should be able to apply some effective filtering to achieve very stable flight.

Test FIXTURE

Up until the last week I’ve been doing most of my testing on a test stand that let the quad pivot on the roll axis as well as a platform that attached each of the four arms to the base.  Prior to the improvements in my PID algorithm, results were very discouraging.  With the new algorithm things looked much better but just not consistent.  I’m pretty sure that my test rigs were just introducing some dynamics into the system that didn’t exist in normal usage.  I may come back to my test rigs but for now, I’m going to focus on actual flight testing.

Go for it!

In my initial flight testing, I was gradually increasing the throttle until it just barely flew a few inches.  This almost always ended up with some sort of flipping.  Then I decided to get a little bold and give it good throttle to get it off the ground and this seemed to work much better (but also resulted in some pretty spectacular crashes, prior to getting close on my PID configuration).  I’m using an XBox controller to fly my quad, one button has a configurable power level for take off, and another one for hovering.  Eventually it will use our sonar for this, but one thing at a time.

Lot’s of room

My first test were in the back yard.  That actually worked well with my off-the-shelf AR Drone, but my Quad is much bigger, has more powerful motors, bigger props…oh and isn’t nearly as stable.  My first few tests in the back yard were just too constraining, it would get off the ground a few feet, but would veer off in a direction for 5-6 feet and I had to kill it before it hit the fence, our house or me :).  Moving to a near by park eliminated this problem.

Stay tuned, hopefully more good news on the horizon!

-twb

Enabling “Pen and Touch” features on your Samsung NP-Q1 UMPC

A couple/few years ago, I purchased a Samsung Q1 UMPC.  It came with Windows XP and performance was adequate, however I configured it for dual boot and install Vista on a second partition.  Performance with Vista was, well, ah, let’s just say the device hasn’t been used all that much recently.

I’ve heard good things about running Windows 7 on older machines so I went through the upgrade process on my Q1.  Windows 7 brought this device back to life (the drivers are easily spotted with a little bit of searching).  The only problem I had was that the touch screen acted like a mouse. That is to say it didn’t have any of the nice features that Windows 7 implemented for “Pen and Touch” or any advanced tablet features.  After doing a bit of research I was finally able to get my device acting as a “Pen and Touch” enabled computer.  It should be noted this isn’t a Multi-Touch device, just a single touch point.

Before you get started, I found it was easiest to just get an external mouse to configure the Q1. 

1. Download and install the eGalaxTouch for Windows 7
2. Copy and extract this driver to your Q1
3. If you have a fresh install you should see something like HID Touch Driver (Universal) under “Mice and other pointing devices” in your Device Manager Note: It will be very close to that, I’ve already upgraded my driver and can’t remember the exact name.
4. We can’t upgrade the default Touch Driver to our new one directly so will need to upgrade to one listed in the devices.
1. Click on “Update the Device Driver”
2. Select “Browse My Computer”,
3. “Let me pick…”
4. Un-check “Show compatible hardware” and look for “ELO TouchSystems” and install that.  The idea here is that we just need something we can upgrade so if you can’t find and that specific one, find one you can install.
5. Reboot your computer
6. Now when you open your Device Manager you should see the temporary driver you installed.  This will probably be under “Human Interface Devices”.  Your touch screen may or may not work at this point.
7. Go through the same process to upgrade your temporary driver, but this time find the folder where you extracted the drivers from the second step above.
8. Reboot again.
9. If all went well, when you select the user you want to login with and see the password box, you will see an on screen keyboard.
10. Once you login, be sure to open Hardware and Sound under control panel.  This is where you can calibrate your device and configure the rest of the Pen and Touch options.

You can also verify that your system is setup properly by clicking on “Computer” and “System Properties”.  You will see Single Touch Input Available.

By the way, don’t let the 1.0 WEI fool you that is just because I can’t run Aero on the device.  For what I’ll use it for, performance is better than Windows XP and much better than Vista.

-ec