Yesterday, and after two weeks of solid work building and programming the new board, I can finally say my quadrocopter can fly! Although the video doesn't show it too well, it is actually incredibly stable once trimmed correctly, I can definitely say it flys far better than I expected for the first run. I would love to try it outside, however it's currently confined to my house due to the 5 days of constant rain and wind we are forecast (and waiting for the glue to set on the second break in the frame, woops).
Now that I have successfully decoded the reciever data I can finally remotely control the quad! This means tomorrow I should be able to take it off its supports and attempt the first flight 😀
After many days ironing out a ridiculous amount of careless bugs plus a major break in the frame I have finally managed to get the PID algorithm keeping the quad level 😀 At this point I *think* it would hover if released from its supports, but for now I would rather improve the code further to get it more responsive still.
The main change I am about to make is switching the output compare modules from PWM mode to single shot. This is because at the moment it takes a full PWM cycle before a new duty cycle can be loaded, adding a 2.5ms delay between the motors and the sensors. By locking the update rate to 400Hz, I should be able to trigger a new pulse as soon as the new duty cycle is calculated, completely removing this delay.
The next task was to take the noisy raw acceleration and drifting angular rate outputs, and combine them into a noiseless non-drifting signal, ideally with no phase shift. The first approach was to implement a kalman filter, a complex cycle eating process. However despite hours of tuning, I struggled to fully eliminate the accelerometer noise whilst still keeping the phase shift to a minimum. This may just be down to me misunderstanding the filters operation, but given how much cpu time it demanded a simpler solution was required. After a brief moment in thought I came up with the following equation: ANGLE=(PREVIOUS_ANGLE+GYRO_RATE*(dt*57.295))*0.99 + ACCEL_ANGLE*0.01. It simply functions by giving the filters a 1:99 weighting, which appears to be just enough for the accelerometer to cancel out the gyroscopes drift:
The system had been allowed to run for a few minutes before this screenshot to allow the gyro drift to build up (red). The blue trace shows the noisy accelerometer reading, and the green is the filtered value.
I have no idea if this type of filter has been used before, but to me it very elegantly utilizes the gyroscopes accuracy and the accelerometers lack of drift, without introducing any negative effects.
Control V4 is built! The specs:
- DSPIC33FJ128P202 MCU
- MPU6050 sensor, providing 6 degrees of freedom (gyro + accel)
- MAX3232 serial level converter
- And some nameless 3.3v 5v tolerant OR gate to combine the four input channels.
I can provide the eagle files for this board if anyone requires them, the board itself is relatively easy to make, as I stuck with 1206 package passives, and chose a DIL package for the MCU. The mpu6050 breakout however was bought, and now I can see its dimensions I am so so glad I didn't try to solder one myself.
Now onto the programming of the board (which has been 16 hours a day for about four days now). The program so far is around 1000 lines (10000 if you count all the header files), which covers the UART setup and operation, configuring the output compare modules as PWM generators to drive the motors, I2C setup and operation, and a driver for the MPU6050. The UART and output compare modules were relatively simple, however the I2C was a bitch and a half to coax into life, mostly because I couldn't get the example I2C code to work with my project, meaning I had to write my own driver. The MPU6050 was also a pain, mostly because my lack of a logic analyzer made debugging the I2C communications very difficult.
Nevertheless, I have now successfully communicated with the sensors, and I must say the raw accelerometer output looks far less noisy than my previous sensors, I cannot wait to get these sensors fused together.
You see that tiny chip on the right, closest to the penny? That's a 16 pin QFN package magnemometer. I'd guess its linear dimensions are around a quarter of that of the previous sensors I got stuck on, and the marginally larger MPU6050 on the left isn't much better. With this realisation I have decided to skip this painful mounting procedure by just buying a pre-built breakout board from a man in Germany. Slightly more expensive, but I'm sure being slightly out of pocket is better than tearing all my hair out at a later date when I get round to the soldering.
Unfortunately, he doesn't seem to have released any documentation on the dimensions of the board, so I can't get the control board designed and fabricated until this arrives, which could be at least a week or two 🙁
My heart just stopped for a moment when checking over this post when I saw the silkscreen text “MPU-3050″. However, upon zooming in the actual chip on the board is still a MPU6050, so I assume the two chips just had identical footprints which allowed the reuse of the old boards. I’ll be going apeshit upon its arrival if this isn’t the case
Today was spent trawling through the mass of MEMS sensors that are now available, at which I am absolutely astonished! The chips on the market now are leagues ahead of their predecessors. For example, when I acquired the parts for my original board, the total came to around £250 for the five sensors, which you can now get in a single package for $15! Plus, the new ones have a much finer acuracy, have a built in adc with I2C output, and even a microprocessor to take the bulk of the sensor number crunching away from the main controller!
Currently it looks like I will be using the MPU-6050 by invensense. The gyroscope has a sensitivity of 131 LSB/°/s, compared to my previous ADXRS620 at around 6.8 LSB/°/s, while the accelerometer has a sensivity of 0.06 mg/LSB, up from 1.22 mg/LSB on my ADXL203's. Sadly the rms noise is only better by about a factor of 10 for the gyro, and 5 for the accelerometer, but I imagine these values will allow the craft to be so level that other effects such as wind and ground effect will have a larger affect on the drift.
The only two downsides are first the 256Hz built in low pass filter on both the gyro and accelerometer, and second the fact that it comes in a 4mm 24 pin QFN package. The LPF I hope will still allow for a fast enough update rate to maintain stability, and I *think* I should be able to manually solder the QFN package, probably with hot air or a hotplate. I just finished designing the required eagle symbol to mount the thing, and will now start building the rest of the circuit around it.
Today marks a sad day. The last of my spare ADXRS620 gyroscopes failed during reflowing, bringing the final total to one success against five failures. Sadly one functioning gyroscope is not enough to keep a quadrocopter in the air, so I am going to have to take a new approach. The reason for these successive failures is simply down to the size of the chips. Each of them is no more than 6 or 7mm wide, and contains 32 pins on the bottom of the chip, invisible to the user once mounted. This makes aligning them for reflowing a massive guessing game, unless you have access to the proper xray mounting machines.
So, my main problem now is I don't have any more gyroscopes. I could probably sample more of the same, but I imagine I would just run into more mounting frustration and delays. Instead, I am going to buy a premade board combining a tri-axis IMU-3000 gyroscope and a tri-axis ADXL345 accelerometer, then I only need to worry about the simpler control board and the coding. Plus, these chips are a lot more modern than the ones I was using, allowing for both a higher resolution and less of a linear acceleration effect. Also they use a 16 bit digital I2C output, meaning I won't have to use the microcontrollers lower resolution 12 bit ADC. This should both reduce the cpu workload, as well as eliminating any electrical noise from the motors being picked up by the connecting pcb traces.
Here is the final picture of the control V2 board, a project I have so far sunk countless hours into, and learned a great deal through.
The new firmware seems to work perfectly so far, plus the speed up times have been noticeably reduced, you can now really feel the kick of the motor accelerating. The only possible downside to this firmware I can think of is increased ohmic losses due to the sudden effective voltage change, where as normally the motors back EMF can grow as the duty cycle is steadily increased to oppose this voltage.
Thanks to a STK500 development board I borrowed off a friend, I finally managed to flash my ESCs to an improved firmware created by SimonK. This firmware reduces the low time in the input PWM from ~18ms to less than 0.5ms, increasing the update rate from 50Hz to around 450Hz. It also removes the digital low pass filter on the input, allowing the esc to respond to commands as soon as they are recieved, a vital property for quadrocopters.
The reprogramming was relatively easy, as the esc already has pads connecting to the programming pins (shown below).