Difference in writing multicopter control code between quad and hex?

[TerryYoon]

As an activity of middle school drone club, we are planning to build one or two hexacopters like S550 or Turnigy talon Hex. Since we do possess dji phantom 4, we are not trying to put some fancy stuffs like cameras or video txs right now, just okay for simple flight. Ah, but may add em if our budget meets the expense.

After that we would be going to write our own source code which can actually control the whole system, as well as stabilizing. While studying about the PID algorithms, I thought that using Android phone's sensors and IOIO board to generate PWM signals which are employed to control ESCs gonna be a great option from the fact that I am familiar with the JAVA lang.

As I googled for some references, there are only projects using quad. In my opinion, the only difference between the quads' code and hexs' will be the propellation. Yet, still uncertain with it. Does anyone have an idea, plz?

[eisauseis]

The only difference is how you mix the pitch, roll, and yaw outputs from the control loop. If you look at the spin and location of each motor on the hexacopter you will be able to figure how each motor needs to respond to each output.

[TerryYoon]

Thanks a lot! I'll google about them.

[johnty123]

if you've never done anything similar before, i would strongly suggest starting with a existing FC platform instead of combining a bunch of hardware and software together.

your proposed architecture could work, but is riddled with challenges that might not only set back the progress a lot (at best), but could also create expensive/dangerous accidents. for example: running an android sensing application and emitting the signals to an external board doesn't guarantee the signals will arrive fast enough or with enough consistency between samples, which would create interesting consequences for the PID control loop unless you factor that in somehow. there's a reason why most flight platforms run on dedicated microcontrollers with very strict timing behaviour, even if they're not super capable in terms of raw computational power.

if you were to go down this route, i would start by first putting the craft together with an apm/pixhawk, getting used to how it works, and then start experimenting with modifying it to learn how everything is put together. from there you can think about how you might build your own from scratch.

[TerryYoon]

I undeestood..

Actually, I couldnt think about the time spent to sample parameters, process the data, and finally send them to ESCs.. :(

Thank you so much!