Hi all! After some pid tuning, but require further adjustment, today i made the first real flight with my "heavy ArduXOcto", i open this thread for sharing my experience if someone else wants build a similar "heavy configuration" using ArduPiloltMega 2560, IMU, GPS and Baro, etc.
I have previously tested more expensive systems like Mikrokopter and Wookong, and unfortunately i think there is still much hard work over the code for make this electronic flight like the competition, but considering the price i would say that goes too well.
I'm still quite satisfied, even though my copter in some aggressive maneuvers tend to wobble a lot, and in the Loiter mode some circles is inevitable because I believe that the management of the accelerometers correction is not optimized or inactive.
Over the baro range i've a good altitude precision, max 20/30 cm of excursion.
This is my hardware configuration:
- APM 2560
- OilPAN IMU
- Mediatek MT3329 GPS V1.6
- XL-MaxSonar MB1200 (with active filter and "thermal mods", 4 x 10 ohm resistor around the case)
- ESC HiModel Pro 30A, in high timing mode
- Two switching BEC 6V 5A (connected to electronics through two diodes 3A, the tension output is 5.33V)
- Motor TigerMotors MT2814 710 kv (mounted with 3° inclination for increase YAV control)
- Props APC 13x6.5 "E" (X8)
- Two-Way telemetry "Mikrokopter Wi232" (890 MHz)
- Six led strip connected to APM (pins AN8<->AN13 through ULN2003), thanks to u4eake for the code
- Homebuilt frame, mixed aluminum / vetronite (by AleBS, thanks dude! :P) + homebuilt hood
- Lipo 4s2p 5000 mhA 40c
- TX Futaba T12FG
- RX Futaba R6008HS
I'm uploading the video on my youtube channel, post them soon, for now I leave you some pictures.
I enclose the parameters used for the flight test in a soft wind, but there's one error, the real "Rate Pitch I" is set to "0".
Yes dear Oliver, and is my intention the evolution of this system also with my little contribute, i like it because is open and free.
I hope in a future with better code debugging for replace all the MK electronics with ArduCopter in all my drone.
At the moment i've only one little crash with Arducopter for a big flutter of some props at very high speed.
Now i make some mods on my octo for remove this problem.
Did you verify that your propeller max rotation speed is higher than max speed of your setup ?
It seems to me quite strange that you got a broken propeller during fly.
With regards to a broken prop while flying.
Obviously it would cause an ridiculous amount of vibration if it doesnt break perfectly symetrically.
With this said. When the prop breaks, the RPM of the motor should shoot through the roof. One could add something to the code that if the RPM goes above a pre defined limit, it cuts all power to that motor.
Well, with the hardware setup we have today, how will the APM know that one motor RPM is rocketing? The software running doesn´t know anything about any motor or ESC, it just outputs PWM levels to the ESCs... Thats where bi-directional communication APM-ESC comes into the picture. As a future feature. I hope.
Adding this kind of smart algorythm in the ESC is certainly something complicated if you want to detect a broken propeller with 100% reliability. It would require a lot of testing and a controler with enough ressources.
Using good quality propellers seems to me the better option.
Simpler is often more reliable.
I broke EPP from MK, is normal, very poor props!
I have repaired my hexa and installed .56 and fixed both bugs, it flies well but not in Loiter, regardless of declination. It is said that the DJI is very stable and, as I know, not two-way communication to the esc's?
Two way communications to ESCs does not give more performance. it is a comfort option because you can program the ESC remotely directly from the radio transmitter or ground station, and get telemetry data (temperature and current consumption).
Obviously if your motors / propellers are well dimensionned, ESC telemetry is not necessary.
Fast PWM is more reliable than ic2 (used on MK) because it is simpler and one way. It is not possible to freeze a PWM output and it is mostly noise proof.
There are many reasons why an i2c bus can be degraded or fully stalled - from hardware glitches to software management problems if using basic freely available i2c libraries.
i2c bus is used at least in one commercial UAV projects and some DIY ESC projects, but obviously it's not a good fit. It was primarily designed by Philips for communication between integrated circuits inside TV set or similar devices in the early '80s. It is not designed for field use, has a very basic physical single ended interface subject to noise and generating noise as well if the signals are not conditionned by filter circuits.
I think DJI use a good accelerometer routine for the stable/loiter mode, because the only way to stabilize better the drone is with interception of little axial movements and its correction, then also the same movement as the corrections.
Of all this, joined the movement detected by GPS, you should make an average but i understand that the routine may too complex to create.
But the source code of MK is public... :-)
On Arducopter this routine is in test, and i tried but don't work fine.
Without this the loiter going to circle, is normal because using only GPS and gyro.
For now i would create a routine that tends to turn the drone by looking in the opposite direction, it could end up working (LOL)... :P
the MK isn't opensource , only FC is open but all the advanced functionality is in navy board that is totally closed source .
Thank you for the good explanation Oliver, the reason for the I2C freeze is maybe because need of hand shake for every transfer with I2C?