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