In my opinion, too much energy is being wasted here on ultra-cheap boards like Kakute, Matek and Omnibus. There is betaflight for those willing to use $20 AIO flight controllers, Arducopter should be focused on reference Pixhawk boards.
your opinion is not the only one. plus, most F7 boards are in fact more advanced than a F4 based pixhawk.
to go into details - IMU is different and better, on kakute and omnibus is it soft mounted, there it embedded proper OSD support, and in case of AIO boards you get a chance to build small 200mm models with fully functional arducopter features.
1 Like
Show me a 20mmx20mm pixhawk, and I’ll try it.
We’ve got to keep up w/ technology here. Things are moving much faster in other areas than in the development of pixhawks.
Everything is getting smaller. I’d bet w/in a few years we’ll have palm sized drones w/ lidar flying through buildings mapping them for architectural drawings, etc. If we wait for pixhawk development, we’ll be flying huge copters with slow hardware development, for years.
And, there’s nothing wrong w/ having options. Different people are working on the development of these smaller boards. Nothing is being taken away from the big pixhawks.
Personally, cost has nothing to do with it. Size and weight are my primary concerns. Being inexpensive is only a benefit.
1 Like
How does that advance the technology? Reference Pixhawk boards that you mention (FMUV3) is old tech. It’s not about “cheap boards” its about the latest technology and advancement…
There is no high-tech in $20 Chinese boards. Intel Edison together w Pixhawk 2.1 opens huge possibilities. NVidia TX1 as well. I really hope Arducopter will take advantage of such kind of hardware.
Those cheap $20 boards have better processors, better design, and better IMU’s than old pixhawks.
And all the things you mention you wish Arducopter will take advantage of… It already does!
And you can use the Edison and TX1 with the $20.00 boards.
It sounds like the only issue you really have with them is the cost… So I guess you want to belong to some exclusive club that money rather than knowledge gets you in to… But that’s not the goal here. We want as many people as possible to be able to use Ardupilot, and inexpensive, more modern, smaller boards only help us.
Plus, like I said before, supporting other boards takes nothing away from the pixhawks. It’s just different use cases. If a big heavy pixhawk is somehow better for your vehicle, then use one.
I love the idea of something like the SkyViper 2450gps having full ArduPilot support. A super-light 250mm class brushed/geared toy-grade quad that is ArduPilot? Awesome!
I hope that smaller AIO boards become more common as I’d love to make my first “racer” build around ArduPilot.
Hi,
A small issue I noticed, when in PosHold mode my OSD (minim) shows ALTH, though mission planner shows the correct flight mode.
HTH,
Gal
OmnibusF4 ProV2/V3 In the external GPS of Uart6, the external compass still cannot be calibrated. It can automatically recognize that it is 466433. The GPS is normal, but the compass can’t be calibrated. Therefore, it is impossible to test the 3.6rc7 Loiter on the traditional helicopter. The mode in which the horizontal position is maintained.
Last week I put a new HERE GPS on to my Jet Ranger scale Heli. It had a 3DR unit on it before.
FC = Pixhawk , 3DR original.
You maybe on to something. Because I also cannot get the new compass calibrated. I also have upgraded the FW to 3.6rc7 just for fun. My compass dance is to much for me it never finishes positive.The program hangs. I gave up several times because I am getting dizzy. That Heli is heavy ( 9kg and I am 69 years old ) , will try again with the 3.5.7 FW which I have not tried yet. I never thought it could be a 3.6rc7 Betta FW problem.
BTW I tried with Mission Planer and Qgroundcontrol both hang midway through.
So it seems that this is indeed a problem with 3.6rc7 FW, Tridge is also very strange, I tried the first to successfully detect the firmware of the external compass, the same can not be used for external compass calibration, I hope the development team can fix this bug as soon as possible.
I want to change the rcmap parameter to 9-12ch.
(I am not good at English, so I get help from the translator. Please excuse me.)
But I don’t know how to modify the code. Is it possible?
My quadcopter installed frsky r9 mini receiver and uses a variety of functions with storm32 gimbal, so it uses the Sbus out function a lot.
because Dshot , I cant use servo1~servo4 for orther function.
Thank you.
I’m using the new HERE GPS/Compass on both 3.6-RC7 and master. It works fine. It is likely you have a compass related parameter set wrong. You do have the compass plugged in (separate from the GPS) and the lights are doing their thing, right?
I don’t know you change rcmap for what. But if your quad is X4, you could set BRD_PWM_COUNT=8 and use SERVO5_FUNCTION ~ SERVO8_FUNCTION for your purpose.
You could also passthrough ch9-12 PWM to main out pin4~8.
Matt, how long does it take you (minutes ) to fill the green lane for the external compass calibration? I never got it to the right edge. It starts fine the FC beeps every second or two but than the green bar stops moving and stalls. I have done it many times on different day,s in different areas. I cannot get it to finish.
I have done compass calibration many times the old way successfully over the years but never finished the new on board calib ones. MP or Qgroundc. the same result. My next step is to go back to older FW and older MP to do it the old way.
thank your answer.
I set dshot esc. dshot must ch9~12 set for motor1~4 out.
so I want use ch9~12 motor out togehter RC in(AETR).
stomr32 3axi gimbal need 6ch( tilt pan camera…)
In both 3.6 and master, ChibiOS is intermittently not respecting BRD_SAFETYENABLE and BRD_SAFETYMASK parameter settings on boot. I opened a bug report this morning on the safety switch. And someone else opened one regarding the mask a few hours later. Glad to see it’s not just me 
Hi Charles,
I looked into the booster issue and I’ve got a potential fix for the output not obeying the safety-switch. I couldn’t replicate the issue with the output not being enabled until the SERVOx_FUNCTION was set to “53” though.
Anyway, I hope this will go out with -rc8 in the next few days (Monday at the latest).
Since Upgrading to ChibiOS an having an intermittent problem arming the copter using the arming button.
Occasionally the Copter will refuse to ARM when the button is pressed. All the prearm checks are completed the only thing I can do is powercycle the machine and it usually works fine. I am using a pixhawk2.1 and Here GPS.
Dont know if it should be logged as an issuse or is it a hardware problem I have only one GPS module
David Ardis
Perhaps related to the safety button issues above?