Encouraged by the success of my previous custom board (Version 2), which happily carries my quad in the air (maiden flight) with some advanced features like self-stabilization, course lock, control loop operating at 400 Hz, etc., I decided to jump on a more ambitious project - the board with more sensors, more ports, etc.
In summary, the new board (Version 3) has the following parameters:
- PIC24EP512GP806 MCU operating at 64 MHz;
- Two MPU-6050 sensors (in the hope to achieve better vibration rejection) - one on the left and another one - on the right side of the board ;
- New HMC-5983 magnetometer;
- MPL3115A barometric altimeter that can be configured to report altitude instead of the raw pressure;
- On-board 3.3V 1A voltage regulator;
- 8 PWM ports for quad-, hexa-, and octo-copters and/or quad and camera control;
- 4 UART ports for GPS, US-100 ultrasonic sensor, UART-enabled RC receiver, and Data Logger;
- ICSP port for programming;
- On-board signal LED and header for connecting external LED or buzzer (powered through MOSFET);
- Standard size with mounting holes matching KK and MultiWii boards.
Here is the board overview (above)
I will be documenting every step of developing (mostly - porting from V2) firmware for this boards as well as sensors' calibration on my blog. Obviously, all the code is Open Source under the MIT License located in the SVN repository.
Comments
Doing the average of 2 sensors will give you a little bit better result, but if you want dramatic results, put the sensor on a tiny PCB board, connected to the main board using a very flexible cable, and have the sensor PCB sandwiched between 2 small peices of moon gel. With 2 sensors like this averaged. Also, you probably need them a little further appart... THAT will give you good results!
The crystal accuracy is definitely sufficient for what you are doing. I thought that with the efforts you were going to to reduce sensor noise that you might be trying to perform long term dead reckoning.
If your current averaging scheme does not perform as well as you'd like, you might consider running one sensor at DLPF of 0 or 1 purely for flight stability control while using the second sensor with a DLPF at 4 or 5 and accelerometer sensitivity set to +/-4g (to increase the resolution) for your short term position change estimation.
In any case I look forward to seeing more of your project.
Phillip,
In terms of clock accuracy the best we can get is a crystal oscillator - albeit without special tuning, which would be tough to do in hobby conditions - is this not sufficient clock accuracy?
I am not planning to do dead reckoning - I would like to get sufficient accuracy on vertical acceleration to provide a "counterpoint" to the barometric altimeter as well as provide altitude estimates between the samples from pressure sensor, which is not very fast. Hopefully between the GPS, barometric altimeter, and integration over vertical acceleration I will manage to get a solid altitude estimate.
Starting from scratch as a hobby is really fun. I've completely written a quadcopter control software of my own to run on the arduino platform. In doing so I have learned a huge amount.
I currently use a quaternion integration technique that is very fast while requiring non of the following: trig functions, square root, divides and no re-normalizing of the quaternion. I believe this technique is unique to me (as I have not found anyone else doing it), but I really wouldn't consider it particularly novel as it uses very common techniques. I'm working on describing it in a blog post, if you're interested I'll send you the link for the post once I have posted the article. My current control cycle runs at 400Hz with an ATmega328P.
I use DLPF=0 for my copters when using the MPU6050 and a divider of 19 (effectively 20) for a 400Hz output rate.
Three years ago when I started this project I was intent on performing dead reckoning navigation through double integration of the accelerometer data. On an 8bit processor this is hopeless as 32bit floats are insufficient since they only are good to 6-7 digits. Also, for long flights (10min+), the precision and noise of the sensors needs to increase by roughly a factor of 4000 based on some rough estimates I made at that time. In addition to these two items, clock accuracy must be very good.
I love your project. Keep up the good work.
Phillip Schmidt
Hi Bill,
Glad to hear from you! Actually, this board has two MPUs - the magnetometer is properly aligned with the axis of the board, while MPUs are each rotated by 22.5 degrees in opposite directions with regards to the X-axis of the board, resulting in 45 degree angle between the MPUs axis. Sample from each MPU will be rotated 22.5 degrees left or right around the Z-axis - depending on the MPU, and then averaged.The values for Z-axis will be just averaged. This averaged result will be the input into DCM algorithm.
I am hoping that by using two MCUs in this configuration I may get less jitter and be able to lower the DLPF value from 3 to 2 or even 1, reducing "delay" imposed by the filtering algorithm. I will share results when I get to that point - probably ib a month or so.
I am also detailing all of my code on my blog http://flightcontroller.blogspot.com/ as it is too large and, maybe, too specialized for DIYDrones site.
Regards,
--Alex
Hi Alex,
I totally get why you are doing this. Its nice to know there are still members of diydrones who still want to "do it yourself". You have put an amazing amount of work into your hardware and firmware. Congratulations.
I am also a fan of the PIC.
I have a question about the relative orientation of your MPU and your magnetometer...
I notice there is a small amount of yaw rotation between them.
Why did you do that?
I assume you account for the rotation in your computations.
Best regards,
Bill
Michael,
Actually I do develop all my code from scratch - no "ports", no "black-box" libraries. I do use ideas of other people, but just as the ideas or algorithms, but never code :) Very helpful for my development work were the articles by Bill Premerlani (member of DIYDrones) http://gentlenav.googlecode.com/files/DCMDraft2.pdf and Starlino at http://www.starlino.com/dcm_tutorial.html on DCM algorith.
All my code is available at https://code.google.com/p/custom-pic-quad/ and I recently started blog http://flightcontroller.blogspot.com/2014/07/introduction.html where I plan to discuss all details of the code.
Thomas, I am definitely not working for Microchip and this is not a master's thesis - a few details about me are here. This is my hobby project - I am just interested in understanding the minute details of flight controllers, and the best way to do it is to build one :)
I am familiar with PIC - have been using them for my hobby for about 10 years and they work fine for me - my control loop (with all the calculations in floating point) runs at 400 Hz on a 40 MHz processor, which probably will somewhat improved with the new board running at 64 MHz. I am querying all the sensors at their maximum speed - for example, MPU-6050 I query every millisecond and average samples for the control loop. While raw power is important, careful programming may provide more benefits. Microchip also provides easy to use and free development environment, which was a big plus when I just started with MCUs.
Moreover, I am not sure I would be able to solder those STM32F4xx processors manually onto my board J I probably will migrate to 32-bit platform when PIC32MZ line will become available (only advertised for now).
Bottom placement of some parts is not an issue for me as I solder my boards manually; anyway, I do not pretend to make a product for sale or manufacturing at this time – I am just investigating some ideas and share my thoughts and designs with hobbyists.
There is no need for a USB interface on my board – it does have an ICSP header allowing for in-circuit programming with a $30 PicKit-3. What would I do with the USB port?
The previous version of the board that I use to fly my quad is very, very stable in the air (https://www.youtube.com/watch?v=kEo5DSe7PDg), but it gives me a rather large margin of error when I try to use integral over the vertical acceleration to estimate current altitude – that’s primarily what I am trying to achieve with two IMUs. Also I found out if I reduce DLPF (low-pass filtering) on MPU-6050 below 3 there is too much jitter in the output. DLPF=3 introduces about 5 msec delay in sensor output due to filtering (typical result for FIR or IIR digital filters) – I hope that by averaging 2 sensors I would get the same stable output with lower DLPF.
By the way, what MPU-6050 setting (specifically, DLPF and refresh rate) are you using in your design?
My LED can play Morse or any other kind of sequence asynchronously – allows me to stick with one LED/buzzer. I split digital outputs in two banks because primarily I plan to use it as a quad, which will provide other four pins for “gadgets”, but this can be reconfigured in SW.
If you need 5V (or any other voltage) on the output pins, it would be really easy to add a buffer on the board you are trying to control. The ESCs I use are happy with the 3.3V signal.
I would like to have full control over the design and programming of my boards – thus making HAL for ArduCopter is not an option. Anyway, it is my hobby – and I am not too interested in converting it into the business enterprise – kills the fun:)
Thank you,
--Alex
1kHz is basically a straight multiple, and won't do as much to eliminate aliasing as two frequencies with different roots. 1kHz and 333Hx will both cause aliasing with frequencies of 1kHz, 2kHz, etc.
800Hz and 1kHz will only both alias at 4 and 8kHz.
Randy, it is possible to run two MPU-6050 at different refresh rates - like 1 kHz and 333Hz; I will check this option as well.
-
1
-
2
of 2 Next