Mikrokopter UAV are very common in Germany. They use their own Brushless ESCs, controlled with i2c by their own Flightcontrol.
From now on, it is easy possible, to convert a Mikrokopter UAV into a fully featured ArduCopter with a Pixhawk or PX4 only by replacing the FlightControl&NaviControl.
The i2c bus from the BL-Ctrl's have to be connected to the external i2c bus of Pixhawk or PX4.
Then follow these steps to turn on support for them:
Re-enabling the Mikrokopter I2C ESC Support for FMUv1 and FMUv2 (Pixhawk).
Mikrokopter ESCs have to be connected I2C Bus on Pixhawk/FMU.
To enable mkblctrl startup add a /fs/microsd/APM/mkblctrl file
In this configuration the ESCs must be ordered in the same order as the ArduCopter is numbering them.
In this Mode all Frametypes of ArduCopter are supported.
To enable Mikrokopter native Frame Addressing (Order) support:
For X Type Frame add:
For + Type Frame add:
With Mikrokopter Frame Addressing, it is very easy to convert a Mikrokopter to ArduCopter. Just replacing
the Flight-CTRL against a Pixhawk, and your are done after initial Setup.
In Mikrokopter Mode there are only X and + Type Quadro, Hexa and Octo Frames Supported.
In Mission Planner the right Frame have to be set.
There can be only one startup File on the SDCard (mkblctrl, mkblctrl_x, mkblctrl_+)
I am using my PX4/Pixhawk nearly one year with ArduCopter and PX4-Flightstack without any problems. It is really working rock solid.
Taking a lot longer than I thought, but getting there. Pretty patched up at the moment for testing purposes.
I've had to disable pre-arm checks to enable the arming or the octo so something is also a problem for my arming button/setup (I've been reading through the google groups thread and the pixhawk/mikrokopter page) (arming worked before adding the mkblctrl_x file).
But my motors don't just automatically spin, which is a good thing...onwards and upwards!
Thanks for the info Marco, very much appreciated. Starting to make more sense now.
DGuerrero, I'll be finishing off the conversion early next week, I'll post back if I have the same issues.
Don, reading DG's post it sounds as if the motors are just 'on' with no control over stopping them.
The motors always spin at zero throttle. Do you mean that they spin without you starting them?
It's like Leon says.
I'm finally usin conventional ESCs because I'm not able to calibrate properly the BL-Ctrl. The motors spins at zero throttle, even when no armed, and the safety button does not work, the red led is always blinkin but i can arm the octo.
the Mikrokopter 5Pin Molex Connector have the following Pinout:
1 = GND
2 = Speaker
3 = SDA
4 = SCL
5 = Battery Voltage (Attention this is direct LiPo Voltage !!!!!!)
You only need the following Pins:
1 = GND
3 = SDA
4 = SCL
The other two leave unconnected.
Did you need to convert the i2c from 5 to 4 pins on your octo? I'm attempting the conversion to Pixhawk at the moment but our mikrokopter has a 5 pin i2c...
I've converted a MK octo on a pixhawk octo, keeping the BL-CTRL ESCs. Everything seems fine but the motor spins at zero throttle, even when no armed. I think I need to calibrate de ESCs but I don't know if it is possible and how to do it. I guess that is not the same protocol as conventional ESCs. Anyone know how to do it?
Another problem, although not very important to me, is that the safety button does not work, the red led is always blinkin but i can arm the octo. Is this normal?
Would you mind explaining how you wired up the ESC to the Pixhawk? As far as I can see, there are only SDA, SCL and GND ports on the Mikrocopter ESC. Are these sufficient connections for the Pixhawk's i2c interface, which also has a 5V port?
Don LeRoi wrote:
"There are some distinct advantages associated with being able to talk to the ESCs and have them talk back to you. Hopefully, we can do that without exposing the I2C bus to outside influences that can shut it down."
Massive advantages: To be able to glance down at the Graupner LED and see ESC temperature, amp pull and I2C errors gives a lot of confidence. Besides this, the update frequency on this bus far exceeds what PWM is capable of, leading to super-stable descents among other things. I can confidently drop my multirotors vertically down to 15m AGL from mission height, at -3m.s without any fear of instability.
I think the catastrophic I2C bus failures on the MKs are largely a thing of the past. All the ones that I've heard of were the result of shorting one of the signal lines, usually because of faulty wiring. Originally, it was up to the builder to connect each ESC to the I2C bus on the flight controller - soldering the signal wires at both ends. With the introduction of the power distribution boards, that wiring mess was eliminated. Granted, the first quad distro board was actually the source of some catastrophic shorts, but that was soon rectified. Can flawed workmanship still lead to I2C bus failure? Yes! I've seen where sharp jumper wire ends have penetrated battery leads that they were rubbing against, connecting full battery voltage to one of the I2C lines and taking out all of the ESCs - permanently. However, that kind of sloppiness could happen elsewhere on an aircraft to disable some other critical piece of the control system and lead to equally dire consequences. There are some distinct advantages associated with being able to talk to the ESCs and have them talk back to you. Hopefully, we can do that without exposing the I2C bus to outside influences that can shut it down.