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.
- I have some new boards coming next week where I spent considerably more time thinking through the ground plane and adding bypass capacitors.
- 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.
- Add some small rubber washers to attempt to isolate the electronics.
- Add some small rubber washers to connect the motors to the frame.
- 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.