Wednesday, January 9, 2013

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. 

image

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

No comments:

Post a Comment