Blogs

Mikrokopter BL-Ctrl i2c ESC support now in ArduCopter with Pixhawk/PX4

Posted by Marco Bauer on April 18, 2014 at 12:00pm

3689587546?profile=original

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.

Arducopter Mode:
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.

Mikrokopter Mode:
To enable Mikrokopter native Frame Addressing (Order) support:
For X Type Frame add:
/fs/microsd/APM/mkblctrl_x

For + Type Frame add:
/fs/microsd/APM/mkblctrl_+

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.

Attention:
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.

 

Cheers

-Marco

E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Don LeRoi June 18, 2015 at 3:48am

    Have you tried waiting to apply power to the autopilot until after the MK motor controllers have initialized? 

  • Marco Paggot June 17, 2015 at 6:54pm

    Well, I tried to dig mkblctrl driver code (it's in nuttx code, see my post here), but it's too complex for my C/C++ skills. Besides I tried making PX4 firmware with i2c debugging tool support, but it also end up bad. It just won't compile right, haven't found reason why, though.

    Concerning init - i2c on those ESCs is pretty "spontaneous". It could power up and give me "all green lights" on ESC, could power up and find no ESCs. As funny as it is, it seemed somehow connected with contact quality on FMU multi connector.

    By the way, i2c3 port on IO station refused to detect anything at all.

  • Andre K. June 17, 2015 at 2:32pm

    Of course, relaibility is more important that reusing the mkblctrl.

    Please be aware that there are at least two hardware versions, and they are rarely updated (due to difficulty by access to the ICP connections)  maybe the different results people have seen are related to that.

    Also, I2C itself, with this few devices, and "so much" idle time should not be a problem - but there may be something related to the detection, a solution could be to capture and analyse how MkCtrl talks to them, or just look into the MKCtrl source, it can be something as simple as timing - you know how "slow" each one runs the "init beep/shake" on boot , all 6 uses good 2-3 seconds to init.

  • David Novick June 17, 2015 at 2:25pm

    Yeah, I totally agree.  The mkblctrl is a good start, but could use some additions.

    I agree with you, reliability is the most important.  I'll give things a try and see how it goes.

  • Marco Paggot June 17, 2015 at 12:32pm

    Well. 

    I tried two different FS (flight stacks). 

    1. PX4 + mkblctrl + console

    2. ArduCopter + ??? 

    First clue was to make connection as reliable as possible, so I did three experiments with i2c bus. Best was solid UTP CAT5E line (two wires). Problem is that no matter how good was connection, system just refused to detect all ESCs. 

    Worst part is that mkblctrl has no debugging support. It is either loaded or not, and you can get a clue what is happening only during driver manual startup via console.

    What's wrong?

    1. You can not query driver what devices are detected once it is loaded.
    2. You can not unload and load driver again to detect devices all over, you need to reboot.
    3. If you reboot with ongoing (not closed) UART USB connection, it hangs till next reboot.

    In short: Between reaction time and reliability, latter has 100% priority.

  • David Novick June 17, 2015 at 12:16pm

    Interesting.  With the Pixhawk, running the PX4 flight stack and the MK I2C ESCs?

    I'll keep that in mind and I go along.

  • Marco Paggot June 17, 2015 at 11:48am

    I have to admit, I've dropped idea with ESC over i2c, because connection was VERY unstable. Motors were getting detected randomly: one, two, four, none. I guess I can not rely on such connection in air, especially concerning fact that copter has on other ways to stay in air. 

  • David Novick June 17, 2015 at 9:43am

    I believe it's supported since 3.2.  I know it talks to the I2C, since the motors _do_ spin (and I can control the speed with the RC TX)

    Worked on this yesterday, and here's what I did to get the Pixhawk working with the MK ESCs:

    Switched to using the PX4 flight stack.

    Placed this content in the /etc/config.txt file on the SD card (I had to create a /etc directory and the config.txt file).  My MK hexa is setup in a "+" configuration.

    set USE_IO yes                       # no = FMU only mode / yes = FMU + IO
    set OUTPUT_MODE mkblctrl   # start the mkblctrl driver on startup

    #
    # The following parameter must ONLY be set, if your Motor Layout is the original Mikrokopter Layout. # PX4 Users should NOT put the following line into the etc/config.txt file on SD card !! # set MKBLCTRL_MODE +               # x / + Frame configuration

    Ran through all the setup steps (Airframe, Radio, Flight Modes, Sensors, Power).

    The battery is required to get good calibration on the Compass.  I could calibrate with only USB power, but I would get mag errors once I powered up the bird with the battery.

    Everything seems happy.  The light blink as they should, I can turn the safety off, arm the system and change motor RPM.

    Now I need to make sure all the correct motors are turning when they should, and tune the flight parameters.

  • Andre K. June 17, 2015 at 5:00am

    Is the MK I2C support in master ?  in 3.2.1 ?  - I could not see it in the source.

  • David Novick June 15, 2015 at 3:03pm

    I've appreciated all the comments on this thread, it's helped me to get where I currently am.

    Where am I?

    Old Mikrokopter Hexa-XL

    MK BL-CTRL 2.0

    Pixhawk w/ APM flight stack running ArduCopter V3.2.1 Hexa

    I2C cable running from MK BL-CTRL to I2C break out board (to Pixhawk I2C)

    Mission Planner 1.3.28

    without the APM/mkblctrl_+ file:

    Safety switch: 4 red flashes & pause (I'm sure that means something)

    Main LED: Flashing blue (Disarmed, no GPS lock) - Good since I don't have GPS connected.

    IO LEDs: B/E off, ACT flashing

    I can press and hold the safety switch to get solid red

    I can arm with the RC transmitter (Main LED is solid blue)

    I can move the sticks around (nothing happens since the motors aren't "connected")

    I can disarm w/ RC transmitter (Main LED is flashing blue)

    I can hold the safety switch to get back to 4 red flashes and pause

    with the APM/mkblctrl_+ file:

    safety switch: fast blink

    Main LED: flashing blue

    IO LEDs: B/E flashing, ACT flashing

    As soon as it finishing its initialization process, the motors start to spin.  So, with just the act of plugging in the battery, the motors will start to spin.

    Pressing the safety switch has no effect (doesn't change to solid red).

    I can arm with the RC transmitter (Main LED is solid blue, motors spin faster)

    If I move the sticks around, the motors change RPM

    I can disarm (Main LED is flashing blue, motors spinning at a lower rate)

    So any ideas on how I can "combine" these two behaviors to get a properly working system?

This reply was deleted.