NiVek QC Milestone - .NET Microframeworks

Last month NiVek took to the sky in controlled flight (more or less) and was a major milestone in my one and one-half year journey back into microelectronics and flying robots :)

Over the past couple weeks I’ve been focusing on the software side of things and achieved a couple of additional milestones.  As of last weekend I was successfully communicating and configuring NiVek through the Windows 8 flight console using WinUSB.  This weekend I completed a port of the .NET Microframeworks onto the NiVek hardware.

I need to give credit to the Netduino folks for publishing their source code that helped this process considerably.  I created a custom USB stack that works with the driverless WinUSB model that’s available on Windows 8.0 and have my code running on .NET Microframeworks 4.3.  At some point, I might organize my code to provide some updates for the Netduino 2 products that are still on .NET MF 4.2.

As a mobile/cloud/client/embedded developer, I see the .NET Microframeworks as an enabler for creating small/cheap smart devices that can easily be customized to work with the cloud.  In fact, another project I have on the drawing boards right now is a programmable zone controller for our HVAC system that will be programmable with NETMF.

So what’s next for NiVek?  My final task before I have the products frameworks completed is to get the Windows Phone 8 app to a point where it can be used to fly the copter.  At that point the goals for V1.0 have been completed.

-twb

QuadCopter with Win8 Flight Console Talk

On August 27, 2013, I presented NiVek QC with a Windows 8 Flight Console to the Tampa Bay Robotics and Microcontroller Group.

As promised here are the materials and links.

Mounts were 3D Printed with my Afinia H-Series 3D Printer, but the Arms where from this FlameWheel kit.

Although the Windows 8 Console was built with Visual Studio .NET premium, Windows 8 Apps can be built with VS Express editions that can be downloaded for free.

The .NET equivalent to the Arudino, programmable in C# is the Netduino, they are pretty cheap and easy to get started with.  If you’re a .NET programmer and want to get started playing with hardware, this is a great place to start!

A great source of information and forums is located at the DIY Drones web site.  In addition parts and supplies can be purchased from the 3D Robotics store, I generally get most of my parts from Hobby King (they have a USA warehouse, otherwise shipping from Hong Kong is a week or two.

Finally if you don’t want to start from scratch and spend countless hours and probably thousands of dollars on parts, there are some off the shelf quad copters I can recommend.  The AR Drone 2 is a lot more than I had expected, it’s actually some very serious hardware.  You need to get some additional parts like Motors, ECS’s and a frame, but for a flight controller, you can pickup an Ardupilot APM for relatively cheap.  The firmware can be customized relatively easy.

Hope this gets you going and be sure to let me know if you get something up in the air (or have some awesome crashes in the process).

-twb

3D Printing – a Brave New World

This year at //BUILD 2013 in San Francisco Microsoft announced native support for 3D printing.  I’ve been thinking about one for a very long time and decided it was time to pull the trigger and pick one up.  There are a number of different models out there, but I settled on the Afinia H Series as see in the picture below:

After doing some research, I settled on this model for a number of reasons, the print resolution down to 0.15mm, price, reviews and availability through Amazon Prime also contributed to my decision.

So before I get into what I’ve learned about 3D printing since my purchase, I’ll summarize the two biggest challenges I’ve had.  First was getting the model to stick to the platform.  For smaller models this wasn’t an issue, for larger ones, it was.  Second when printing with PLA, I could it incredibly difficult to remove the support material (more on this later).  At this point I’m printing specifically with ABS and it seems to be working fine.  Again more on the materials in a bit.

Lessons Learned

After spending about a month with my printer, I can share the following tidbits of knowledge:

Getting/Creating your models

To begin with, you need something two print.  Printing is really a two step process, the first is designing your model, the second is printing it.  Currently you need a modeling tool to create your model, next you’ll need the software that comes with the printer.  The printer specific software just takes your exported model (typically a STL file) massages it into a set of instructions and then sends instructions for each layer that needs to be printed to the printer.  This is the part that Windows 8.1 will make easier with native support.  Once a modeling program takes advantage of the native drivers you’ll be able to print directly from your modeling program.

The best tool I could to date for creating your models is OpenSCAD, what I really like about this program is the fact that instead of using your mouse to create the 3D models, you program them.  This allows for you to very quickly an even more important precisely create your models.  You can read more on the programming language here.  But here is an example of a mount I created for NiVek using this tool. 

And here’s pictures of the end result:

And finally it mounted on the top of NiVek (note the circuit board is sitting on a custom mount that was also printed.  This really eliminates most of the vibrations before they hit the Gyros.

Here’s a little more detail on what the programs look like, although it might look a little intimidating to get started, it’s a very natural way of describing the part you want to create.

Once you created your program, you press F5 for a quick preview (a little better than a wireframe) then press F6 to compile a complete version of your model.  Once you’ve done that, it’s as simple as clicking on “Design->Export as STL” and you have a file you can pickup with your printer software.

In the case of my printer it comes with their proprietary application that will load up the STL and let you manage your printer:

This software is fairly straight forward to use, you can’t modify the model, however you can adjust the positioning on the platform.  It also adds and support material and rafts necessary to make the model adhere to the platform.

Creating the “Print”

First you need to select your material, the two primary choices are ABS and PLA, here’s a decent post that compares the two.  So far, I’m starting to get things figured out with ABS and can for the most part get predictable results.  Once I master that type of plastic, I’ll go back to PLA, but my initial attempts with it, weren’t very successful.

What do I mean by mastering 3D printing?  Well, right now most of the prints I do are fairly large, about 5x5, my print platform is only slightly bigger than that.  With smaller prints, most of the time things worked fine, but with these larger prints, I was having a difficult time with the edges coming up and thus warping the model.

There were three things I found that were extremely helpful in getting my models to stick:

• Leveling the platform - with my Afinia, I have three leveling screws under the platform.  The goal is to use those screws to adjust the platform so the print head is with 0.2 mm on the four corners and the center.  This is about the width of a standard piece of paper folder over, or a cover for a CD.  I found the best way to do this was to take something a little wider.  In my case a circuit board that is 1.6mm then adjust the platform so the circuit board slid just between the platform and the print head with no space.  This is much more difficult than it sounds, but once completed, I simply moved the platform up 1.4MM (1.6mm – 1.4mm = 0.2mm as specified) and set that for the platform height.
• Preparing the platform – I’ve had good luck with perforated FR4 board (3 of those came with the printer) however they seem to warp and the wholes got filled, in addition in some cases it was difficult to remove the model.  Replacements were $24 each, this seemed rather steep. One of the next things I tried was “painting” and ABS/Acetone solution onto a borosilicate glass plate, this actually worked well but was very messy, scratched easy.  I’ll probably revisit this since you can print without a raft (support material) What I finally settled on was Kapton tape on that same borosilicate glass plate.  So far this seems to be working fairly well.  If the tape get’s scratched or small chunks come up, you can simply patch the whole.  Also at about $45 for 100 feet, I can replace it fairly simply, well after you know the tricks.  I found this method works well for applying the Kapton tape.  Also I’ve found starting from one side and using a credit card to press on small areas of Kapton and squeeze out the bubbles seems to work fine.
• On my Kapton coated borosilicate, I’ve found a little hairspray helped.
• Preheating the platform – Ok, I probably should have done this sooner, but I’m not very patient.  Damn-it if I wanted to print, I don’t want to wait.  Pre-heating the platform to about 90 degrees Celsius (takes about 10 minutes) also seemed to help.

Again these were primarily required for larger models, since I’ve been doing the above, all my models have been sticking.

In addition, there is currently  no way of controlling the temperature of the extruder nozzle on my Afinia (which doesn’t make sense, seems like it’s just software) so unless you want to purchase premium filament all the time (about twice as much per weight, spools are smaller and more expensive) you need to set the temperature a little lower.  This can be done with this switch.

Anyway, the more I use my printer and get it figured out, the more I like it.  My only complaint about this model is the smaller platform.  At 5x5 I’m somewhat limited on what I can print, but I think this was a good entry level printer and so far have no regrets.

-twb

NiVek QC - Initial Flight Videos

Prior to heading to //BUILD/ this year, I took some videos of NiVek QC with my HTC 8x Windows phone, flying it with one hand and capturing video with the other was a bit challenging but I was able to get a few good snippets.

Flying NiVek is 100% accomplished with a Windows 8 app through a wired XBox 360 controller.

The firmware running NiVek in the videos didn’t have any altitude stabilization algorithms in place.  Over last weekend, I added altitude hold as well as a “black-box” recorder that captures telemetry and allows for playback to help do tuning of the algorithms.  Hopefully this week will bring the opportunity for more flight testing.

Videos

 

And the result!

-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

Next Tampa Bay NETMF Meeting/Rise and Fall of NiVek QC4

For all of you that experienced the violent death of NiVek QC4 at the last NetMF meeting, I’m happy to report that with a fresh set of propellers, all the systems checked out and I’m ready to tempt fate again with all fingers still attached.

Our next meeting is scheduled for Thursday March 28^th at the Microsoft Office with social/dinner starting at 6PM and formal talks starting at 6:30. Topic looks really interesting, Joseph Bisaillon, Lloyd Sparkes, Jordi Lucero, and Sean Dunford will be discussing “Zeo Mobile Sleep Manager” and the possibilities of lucid dreaming…I’m NOT going there! Randy will also being doing an intro to using a logic analyzer to build on some of the concepts that Tim started in the last meeting.

http://www.meetup.com/Tampa-Bay-NET-Microframeworks-Developer-Group/events/104804932/

I think starting in the April/May timeframe there has been a considerable amount of interest in Home Automation, we might try to start focusing our efforts on that and get back to the hands on approach we started in the first few meetings so start saving up for some hardware! Once we get a little closer, I’ll start putting together some shopping lists.

I promise no un-controlled flight of my quad…well at least I’ll do my best to get the 1’s and 0’s in the right order and test it a little more beforehand =D

-twb

NiVek GO! QC3 – Status Update

I know it’s been a while since my last status update, but my free time is getting ever so scarce.  I think I can see the light at the end of the tunnel though.  I’ve came a long way since my measly little STM8S103 with a tiny bit of RAM and ROM and I’ve settled on the mighty SMT32F405.  This chip runs at 168Mhz, has tons of RAM and ROM and even has an FPU so I’m no longer scared into using fixed point math everywhere.

This chip is so powerful, my ultimate goal is to lay in a NETMF layer on top of the native C code controlling the Quad Copter.  Also, least we forget the initial early versions that were Netduino GO! modules, this board will also act as a GO! module as well.  One that itself is programmable via NETMF.  So bottom line is my current hardware platform will support the following configurations:

• Stand-Alone, with either an RC Controller, a Windows Phone 8 or Windows 8 Front End.
• Stand-Alone, but programmable in C# and controllable with RC/WP8/Windows 8
• As a C# programmable GO! module with any of the features above.

This platform should provide a very interesting starting point to allow folks that don’t want to get in the mud of low level C and assembler programming the ability to highly customize the software.

In addition as you can see in the picture, I’ve came up with more options for telemetry.  This one uses a 900MHz radio to get get distance of 1KM+.  The other options available are WiFi, Bluetooth and XBee. 

Some additional “cool” things I’ve added to this new firmware:

• Utilization of the FPU, this thing is FAST, and it also is really nice to work in float rather than scaled decimal for all the calculations.  It really cleans up the code
• All the I2C communications with the sensors can be either sync or async.  In most cases in the past pulling the data from the sensors consisted of about 300-400 uSeconds of I2C communications followed by another 100 - 200 uSeconds seconds of processing. With the async and FPU, this went down to no time at all for the I2C transfer and usually 10-50 uSeconds.  I know a uSecond doesn’t sound like a very long time, but when you do things 200-400 times a second, well it adds up.
• Using built in sensors FiFo (First-In, First-Out) buffers to really speed up the sample rate for the gyros and accelerometers.  These are now sampled at about 800Hz and the data pulled and processed at 200Hz.  This means each time the data is pulled we pull four samples.  This is why the async process for reading all those bytes via I2C is important.
• I had another important realization for using the Gyros.  The Gyros read the rate of rotation, not the absolute angle/rotation, therefore the gyros outputs need to be integrated over time to get a good estimate.  In my prior version, I was maintaining the deltaT or time interval used for the integrator, this was even using a scaled decimal approach.  Basically use a timer to find the time between readings and use that as part of the integration.  With this version, I’m just using the sample rate from the gyro, that is to say if that device is internally reading values at 200Hz, my period for integration will always be 5ms, it will always be 5ms.  With an IRQ coming in, I can ensure I always can get a sample.  This is even more important with the FIFO.
• Implemented the PID controller for all four things I care about, pitch, roll, heading and altitude.
• Implemented a very clean complementary filter that is 100% configurable via the flight console in Windows 8
• Implemented a generic filter method that can be configured on via the flight console to filter as either an LPF, Mean, or Moving Average.  This worked out really nice and can be used on any measurement in the sytem.
• Almost everything in the application is considered a “sensor”.  Each sensor has a set of function pointers for different things like Start, Stop, Process, Init, etc.  Each sensor can also be configured with a sample rate.  This means each “sensor” can be treated as an abstract item that can be configured in a common way.  It’s really do some OO things in low level C.

Anyway, time to stop writing about software and continue to writing the software.  I’ve got everything I need coded, now it’s just time to desk-check everything and see if this thing actually flies.

Stay Tuned!

-twb

NiVek GO! QC1 – Part 6, New MCU

Since my last update about 1 1/2 month ago work client work has been extremely busy, I’ve spent a good chunk of time getting a high-end Windows 8 application ready to submit to the marketplace.  Oh and I spent a week out in Redmond at Build 2012.  Needless to say my “hobby” of building a quad copter suffered from lack of attention.

Since my last update, I did however undertake a major shift in technology.  I went from using three STM8S 8 bit micro controllers to one STM32F0 32 bit micro controller.  In a nut shell my software was working great about 99.999% of the time, however for this type of application, it really needs to be 100%.  Even a failure 1 out of every 100,000 times could be very dangerous with the sharp propellers and uncontrolled flight.  100,000 seems like a pretty high number but considering my flight control loop operates at 200 times a second, it does happen.  I think the problem is that my inter-processor communications was just to chatty, I had considerable amount of code firing and handling messages between the micro-controllers and the .NETMF host.  The communications state machines handling these messages ended up being fairly complex and very timing critical.  To achieve a 200Hz update rate, we needed to have very fast SPI communications.  To achieve very fast SPI communications the interrupt handlers needed to be very efficient.  At one point I was troubleshooting using my data analyzer and measuring the microseconds required to process the data, there just wasn’t much breathing room between bytes.

So enter new hardware and an STM32FO.  My initial prototype board also has an STM32F4 on it.  The idea is to implement the GO! Bus protocol V1.5 and have a fully functional GO! module that is self contained and performs all the functions required to maintain stable flight on the quad copter.  Then periodically send state information such as position, time, pitch, roll, heading back to the GO! main board to allow for creating command and control functionality in C# and NetMF.  This was the primary goal, but in the original three STM8S architecture, the GO! main board primarily acted as a message forwarder.

Here’s my new stand alone Hardware, the STM32F4 running NETMF is in the upper left and the STM32F0 is in the bottom right.

So far I have about 80% of the 8 Bit C code for the STM8S’s ported to the STM32F0.  I’m finding that unlike using the three STM8S, most of my code is actually being used to control flight, not handle communications.  It was easier than I had expected and as much as I really don’t like using Eclipse, it’s far better than the ST Visual Developer that I had been using on the STM8.  I found this great article on getting going with 32 bit development for STM using eclipse.

-twb

NiVek GO! QC1 – Part 5, New Electronics

Over the weekend, I had time to assemble my new electronics module for NiVek.  This one had a more thought-out ground plane, a second gyro (added the STM L3G4200D to compare it’s performance to the ITG-3200) and some other small mods.  The big difference in this board however is a set of female connectors on the bottom of the board to snap onto the Netduino GO! mainboard as seen in the pix below:

One of the challenges I’m going to have assembling this board is the alignment of the female connectors on the bottom of the board.  They have to be exact so the line up with the sockets on the GO! mainboard.

This new design required the creation of a development-jig to program the micro-controllers as well as hookup the data analyzer.  Here’s an ugly homemade board I whipped together to accomplish this goal until I the ones I ordered come in (note the blue/white glow from the GO! mainboard)

Finally a couple pictures of the final assembly, so far all the systems check out. 

 

I’m anxious to get it installed on my quad and see how it does.  I have high hopes

-twb

NiVek GO! QC1 – Part 4, Lessons Learned (to date)

Yesterday was my first public power-up demo of NiVek GO! QC1 at South West FL Code Camp.  At this point, I’m very happy with the state of all the software components created, they seem to be very stable and fairly robust and have plenty of band-width for future enhancements.  The following are the primary chunks of software I’ve developed for my Quad:

• Three GO! modules written in C – one for reading sensor inputs at 200Hz, another for communicating via WiFi and a third for controlling motors and reading inputs from the RC Controller.  All this software is running on STM8S207’s micro controllers running at 16MHz.  These have 32KB ROM, 6K RAM and a little bit of EEPROM.
• Netduino GO! “Command-and-Control” software written in C#.  This software communicates between the modules and really provides orchestration of all the sub processes that make up the Quad.
• Flight Console – written in C# running on Windows 8 as a Metro, er-ah, whatever they end up calling the new style tablet apps for Windows 8.

At this point I have all the software controlling the hardware but I’m struggling with the most complicated part (at least for me to-date) in building my quad, achieving stable flight.  I’m actually getting fairly good results now with my test rig running on a single axis, but attempting to get more than a few inches off the ground and maintaining stability is turning out to be more challenging that I expect.  Remember the goal here is NOT to use the RC controller to control the pitch and yaw, but to measure the error and then update the power to the corresponding motors to compensate for those errors.  The RC controller (and eventually the Windows 8/Windows Phone apps) will be used to send a command to the “fly-by-wire” system of the quad.  Then the quad will figure out what it needs to do to make those commands happen.

Lessons Learned and Next Steps -

Noise on Accelerometer

One of the biggest differences I’m seeing between just developing the software on a development board and using it on the quad with the motors running is the amount of noise in the accelerometer.  With a low pass filter of about 10Hz running, I’m seem very stable output from the accelerometer without the motors (+/- 0.25 degrees).  With the motors running, I’m seeing unacceptable noise of about +/- 10 degrees.  Since gyro is extremely stable and the accelerometer is only used to compensate for drift, the accelerometer doesn’t have to be super accurate and noise free, but it does have to be better than +/- 10 degrees.  I haven’t tracked this down to be electrical or mechanical, however here are my next steps to minimize the noise.

1. I have some new boards coming next week where I spent considerably more time thinking through the ground plane and adding bypass capacitors.
2. My current quad frame is plywood, I’m going to try a different one that is aluminum with a carbon-fiber deck for mounting the electronics.
3. Add some small rubber washers to attempt to isolate the electronics.
4. Add some small rubber washers to connect the motors to the frame.
5. If I’m still seeing the noise, I’ll take a look at balancing the propellers.

Update rates on the ESC.

I’m currently using the stock firmware on the ESC (electronic speed controls) that are used to take the output from the micro controller and power the motors via PWM.  The stock firmware only allows an update rate of 50Hz to control the motors.  In addition, after doing some research, I’m seeing that this is even filtered a bit more and I might only be getting about a 20Hz update rate, this really doesn’t seem fast enough.   I found a great post on RC Groups that discuss how to flash new firmware on my ESC’s that should allow for a faster update rate.  This still uses PWM but looks like it might allow and update rate of 400Hz which would be fast enough for the system to grow into. 

As a couple sides notes on this:

• Since it looks like I’ll probably end up flashing the ESC’s I might look to using something other than PWM to communicate with the speed controllers.  It doesn’t seem like it might be all that much of a stretch to go to I2C or even something really crazy like using a custom GO! module with some FET’s, but this probably won’t be something that will happen in the near future.
• The firmware I’m going to flash is actually written in assembler.  It probably sounds crazy, but I really wouldn’t mind getting my hands dirty and seeing what I can do to really make my ESC’s play nicely with my GO! module.  I never thought I’d see the day when I would have the need to write assembler again.
• Right now I’m only using 100 graduations from idle to full throttle.  That is to say I can only specify an integer value of 0 to 100% to control the PWM and thus the speed.  My initial gut (which is usually correct) says that resolution is probably the best I can expect from the ESC/Brushless motor combination.  However now that I’m seeing the quad in action with the motors running, it almost seems like small difference actually make a bigger difference in the RPMs.  I might want to do some tests, I’m thinking I can use some sort of IR Sender/Receiver and a little app that counts pulses, then I could measure the RPM of the propeller and see how it response to different inputs.  This would also be very “interesting” from a before-and-after perspective of updating the firmware on the ESC’s.

 

Allow for additional configure of the sensor and GPIO module.

• The accelerometer and gyroscope have some register based settings to control things such as filter frequencies and update rates.  Right now these are set as constants in the firmware.  These can just as easily be read from the EEPROM after being programmed from the flight console (similar to how the PID values are being configured).
• The accelerometer has a high-pass filter implemented on the STM8 that should be configurable via the flight console.
• The complementary filter has some constants on how the Gyro-scope and accelerometer are combined.
• There are at least two common approaches to combine the gyro and accelerometer.  I chose a complementary filter since it was easier to implement and doesn’t require as many CPU resources as a Kalman filter.  Since it looks like my little STM8’s aren’t working that hard, I might go ahead implement the Kalman filter or investigate the “Extended Kalman” filter has demoed in this video.
• Right now the PID constants are linear.  That is to say, the P or proportional component applied to the error is the same if the error is 20 as it is if it is 2.  Might want to consider having two sets of PID constants, one for “really-bad” errors, this will probably only use the P component.  Then when we get to the point where we want to fine-tune the correction factors, have a different algorithm or set of constants.

I have a fairly large client deliverable due in September but hope to have the majority of the items completed by the end of the month.

-twb

NiVek GO! QC1 – Part 3, Test Fixture/PID Controller

In my continuing effort to get my .NET quad copter off the ground, I’ve created a quick video to demonstrate the test fixture and software I’ll be using to achieve staple flight.

Enjoy!

NiVek GO! QC1–PID Tuning Fixture

-twb

NiVek GO! QC1 Video – Part 2

Here's another quick and dirty video of NiVek GO! QC1 a .NET Microframeworks application with a Windows 8 (and coming soon Windows Phone 8) Flight Console

In this one, I'm spinning up the four motors on the quad copter although I'm a little timid to try to fly it in the cramped quarters.

 

As noted in the video, I'm seeing a lot of noise in the accelerometer when I power up the motors, but the gyro is clean.  Using a complementary filter I'm getting decent attitude readings (pitch/roll), but it's still bouncing around a couple of degrees, if anyone has any suggestions on how to isolate and cleanup the problem, I'd love to hear them :)

Next up is hook in the pitch/roll or error information into the PID controller and see how it flys.

Stay tuned!

-twb

NiVek GO! QC1 - Part 1

As a follow up to my initial post on NiVek GO! QC1, I shot a quick and dirty (read as: one-take and no editing) of the software and hardware working together to control a brushless motor and display sensor outputs from the Gyroscope and Accelerometer.

NiVek GO! QC1–Part 1

-twb

NiVek GO QC1 Makes its debut at Tampa Windows 8 User Group Meeting

On August 8, 2012, the NiVek GO! QC1 (Quad Copter1) built with Microsoft .NET technologies will make it’s debut at the Tampa Windows 8 User Group meeting. 

You may ask what does a Quad Copter have to do with Windows 8?  Well, the flight console as pictured below runs on a Windows 8 Slate.

Not 100% a metro app, but it’s not a typical application either

The “brains” or flight computer behind the quad copter is really in four parts.  Yes, that’s right there are four processors use to power the copter. First is a board I designed that has 3 STM8 chips a bunch of sensors and some EEPROMs used to keep data when the power is pulled.

The second is the new Netduino GO! board

You can see how they are connected in the following picture, via something called SPI.

Do you really need four processors?

You may ask, does it take four processors to drive a Quad Copter.  The answer is: well probably not, however a quad copter is inherently unstable and it does require a good amount of processor power to provide a “fly-by-wire” mechanism to keep it stable.  The idea here is to use a modular approach where each processor has an assigned responsibility, it does only one or two things and it does them very well (or what’s important here, very fast on a very highly predictable time frame).

What do each processor do?

GO! Main Board – The Netduino GO main board provides orchestration of flying the copter.  The software for this is primarily written in C# running on the Microsoft .NET Micro Framework. Not really time critical things but more strategic.  Things like routing messages between the different modules.   Considerably more on this to come in future posts

Sensors Module – It’s one responsibility is to figure out the attitude of the quad copter, that is to say the pitch, roll and yaw.  This also has sensors for altitude and a GPS.  The sensors in the first generation of my board are a 3 axis gyro ITG3200.  A 3 axis accelerometer and 3 axis magnetometer (electronic compass) LSM303DLHC.  A sensor to measure air pressure (which can be used to accurately determine altitude) BMP085.  And finally a fast GPS module (10 updates per second) UP501.

Flight Control Board – This really has three main functions:

1. Quad copter is flown by a standard Remote Control transmitter.  The first task of the flight control board is to take the PWM (Pulse Width Modulation) from the receiver and turn it into inputs for the flight control computer.
2. Next step is the fly by wire algorithm.  This takes the current attitude (how much the quad copter is tilting in the X/Y plane) and combines that with the input from the RC receiver and figures how how much power needs to be applied to each motor to keep the Quad Copter from crashing.
3. Finally the Flight Control board takes the power to be applied to each motor in the form of a percentage and changes that into another PWM signal that is applied to the ESC (Electronic Speed Control) that controls the brushless motors.

Telemetry Board – The primary purpose of this board is to establish a link from the on board computers back to the Windows 8 (and eventual Windows Phone 8) consoles.  This uses the RN-171 WiFi module and an STM8S207 chip to provide these services.  This modules purpose is very simple, take a byte array in very quickly via SPI, buffer it and then send it out via WiFi.  It also listens for commands from the flight console and relays them to the GO! main board for processing. 

Couple final pictures

This is the control board mounted on the Quad Copter Chassis.  The white stuff is the Gorilla Glue I used to hold everything together.  Didn’t realize how much of a mess it would make .

 

Close up of the Brushless motors and the 10” propellers.

What’s next?

Tonight I only have a brief amount of time to cover this project, for a more detailed run through of the hardware/software, please attend my session at the SWFL Code Camp in Napes on September 8.  I’ll probably be flying it over lunch.

In addition over the next couple of months look for many more posts along with the publishing of the hardware and software for the NiVek GO! quad copter platform.

Until next time!

-twb