I think at the moment EMLID is way too slow in supporting new hardware and new ardupilot releases.
We can see new sonar, new precision landing hardware and a bunch of new ardupilot releases and we can’t use them because the standard answer is “not supported at the moment, more important things to do now”.
I think in a fast moving market as it is now that of the “Drones”, support needs to be faster and almost real time with that of the leading hardware (pixhawk at the moment).
This wants to be a constructive criticism, i anyone gets offended by this than ok
p.s. I think develop of Reach is taking too much effort out of EMLID to support Navio, and in the end Reach is a really subpar product for what it is supposed to do (90% of people can’t get decent performance out of it).
Constructive criticism is good but I think this is misplaced. I’ve been following your other thread on IRLock IRLOCK and I2C.
First and foremost Emlid doesn’t support third party products. I often saw that as a blah thing but now I clearly understand why businesses take this route.
Emlid came out and told you what to do, IRLOCK and I2C and you didn’t do it. That is fair, I understand not everyone is a developer so you need to be patient. If you want to apply pressure you need to do it politely and at the right person/company.
An Emlid employee ‘hacked together a driver’ as a nice gesture but wasn’t able to test to release it as it would put them in a bad spot if it nukes your drone.
I told you to contact IRLock and ask them to support it as it is their product and their implementation. IRLOCK and I2C
IR Lock then commented on the thread that they have a working implementation IRLOCK and I2C in 3.4-rc5.
At this point I’m guessing you assumed that Navio support was merged in ArduPilot code base or you are still thinking it maybe a Navio hardware issue. You confirmed it wasn’t an I2C issue when lowered to 400Mhz and was detected via i2c tool. IRLOCK and I2C Looks like all of Emlid’s stuff is working and is a ArduPilot issue.
Since then IRLock hasn’t provided any updates on the thread for their product while you have been posting asking Emlid to provide support on a product that isn’t theirs.
You are claiming Emlid is holding this back but I fail to see how. If IRLock submitted a Pull Request and it got merged in ArduPIlot, you are more than welcome to compile ArudPilot master on your own. It isn’t hard and takes about 30 minutes from start to finish. It says directly in the docs https://docs.emlid.com/navio2/Navio-APM/installation-and-running/
Support for Navio or Navio 2 should be HAL_BOARD = HAL_BOARD_LINUX. So when IRLOCK said they had working code in 3.4-rc5 that must have meant internally during development and they haven’t started the process to add the code to ArduPilot master so you or Emlid can compile it.
So like I said already, this constructive criticism needs to be aimed at IRLock as the code in ArduPilot seems to only support PX4. Again, it is their product and their implementation.
P.S. Taking shots at the Reach is very distasteful. The Reach is a whole different category and conversation and has literally nothing to do with flight controller or IRLock at all.
We flight test every build before pushing an update to our users, that is why we do not immidiately release new RCs through our repositories, however no one restricts you from installing latest firmware straight from http://firmware.eu.ardupilot.org/Copter/, or even building it yourself from the repo. Navio2 is fully supported in ArduPilot master, so every new build is automatically compatible with Navio2.
You should not feel like Navio2 is not getting love from us, right now we are preparing a new image with new exciting features
@mr337 Thank you so much for your detailed answer, I couldn’t have said it better.