New features and new hardware support

Corrado_Steri · October 29, 2016, 12:11pm

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

Corrado

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).

mr337 · October 30, 2016, 5:24pm

Constructive criticism is good but I think this is misplaced. I’ve been following your other thread on IRLock IRLOCK and I2C - #13 by panky.

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 - #6 by george.staroselskiy 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 - #19 by mr337
IR Lock then commented on the thread that they have a working implementation IRLOCK and I2C - #21 by thomas_irlock 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 - #3 by Corrado_Steri 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/

And if those instructions are too hard ArduPilot has a whole doc on compiling, ardupilot/BUILD.md at master · ArduPilot/ardupilot · GitHub

But all of the above is under the assumption IRLock has added this support. I checked the master branch of ArduPilot and found they are pushing IRLock updates.

github.com

ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L17


      
              b) Gremsy gimbal fix when attached to autopilot's serial3 (or higher)
              c) Landing detector fix with large AHRS_TRIM values (>0.1)
              d) MambaF405 2022 gets VTX power on support
              e) MCU voltage enabled on H757 CPUs (including CubeOrangePlus)
              f) PiccoloCAN fix for ESC voltage and current scaling 
              g) Servo gimbal mount yaw handling fix (only affects 3-axis servo gimbals)
          ------------------------------------------------------------------
          Copter 4.3.4 01-Mar-2023
          Changes from 4.3.4-rc1
          1) Lua script PWMSource feature disabled (will be back in 4.4.x)
          ------------------------------------------------------------------
          Copter 4.3.4-rc1 14-Feb-2023
          Changes from 4.3.3
          1) AutoPilot specific enhancements
              a) CubeOrangePlusBG support
              b) Foxeer ReaperF745 supports external compass
              c) MambaH743v4 supports VTX power
          2) Precision landing option to resume tracking target after pilot repositioning
          3) Bug fixes
              a) Arming check fix for terrain following with rangefinder (failed if terrain db was disabled)
              b) Arming check fix if BARO_FIELD_ELEV set

github.com

ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L110


      
              i) Siyi A8 gimbal support fixed
              j) Windows builds move to compiling only 64-bit executables
          ------------------------------------------------------------------
          Copter 4.3.1 05-Dec-2022 / 4.3.1-rc1 17-Nov-2022
          Changes from 4.3.0
          1) Autopilot specific enhancements
             a) ARKV6X support
             b) MatekH743 supports 8 bi-directional dshot channels
             c) Pixhawk boards support MS5607 baros
             d) SpeedbyBee F405v3 support
          2) DroneCAN Airspeed sensor support including hygrometer (aka water vapour) readings
          3) EFI support (electronic fuel injection engines)
          4) Pre-arm warning if multiple UARTs with SERIALx_PROTOCOL = RCIN
          5) Siyi gimbal support
          6) Bug fixes
              a) Arm check warning loses duplicate "AHRS" prefix
              b) AtomRCF405NAVI bootloader file name fixed
              c) BRD_SAFETY_MASK fixed on boards with both FMU safety switch and IOMCU
              d) Compass calibration continues even if a single compass's cal fails
              e) Gremsy gimbal driver sends autopilot info at lower rate to save bandwidth
              f) Invensense 42605 and 42609 IMUs use anti-aliasing filter and notch filter

What I don’t find are any IRLock updates that support the Navio.

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_IRLock/AP_IRLock.h#L14


      
          *  Created on: Nov 10, 2014
          *      Author: MLandes
          */
          
          
// @file AP_IRLock.h
          // @brief Catch-all headerthat defines all supported irlock classes.
          
          
#include "IRLock.h"
          #include "AP_IRLock_I2C.h"
          
          
#if CONFIG_HAL_BOARD == HAL_BOARD_SITL
          #include "AP_IRLock_SITL_Gazebo.h"
          #include "AP_IRLock_SITL.h"
          #endif

https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_IRLock/AP_IRLock_PX4.cpp#L25

github.com

ArduPilot/ardupilot/blob/master/libraries/AC_PrecLand/AC_PrecLand.cpp#L96


      
          // @Description: X position of the camera in body frame. Positive X is forward of the origin.
          // @Units: m
          // @Range: -5 5
          // @Increment: 0.01
          // @User: Advanced
          
          
// @Param: CAM_POS_Y
          // @DisplayName: Camera Y position offset
          // @Description: Y position of the camera in body frame. Positive Y is to the right of the origin.
          // @Units: m
          // @Range: -5 5
          // @Increment: 0.01
          // @User: Advanced
          
          
// @Param: CAM_POS_Z
          // @DisplayName: Camera Z position offset
          // @Description: Z position of the camera in body frame. Positive Z is down from the origin.
          // @Units: m
          // @Range: -5 5
          // @Increment: 0.01
          // @User: Advanced

github.com

ArduPilot/ardupilot/blob/master/libraries/AC_PrecLand/AC_PrecLand_IRLock.cpp#L6-L7


      
          : AC_PrecLand_Backend(frontend, state),
            irlock()

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.

Corrado_Steri · October 30, 2016, 5:37pm

I tought this critics i have done would have been interpreted as an IRLOCK support vent. It is not, i am referring to all other hardware and RC5-6-7 not yet supported as a direct update.

Regarding Reach, i referred to it because from the activity on the forum it looks like all EMLID effort goes toward that product and leaves Navio a bit on its own.

I still think EMLID could be a bit more reactive in releasing new hardware support and new RC as a direct update. If majority of people think it is all good as it is now than i am wrong, sorry for it.

Corrado

mr337 · October 31, 2016, 3:05am

I did not get this from your original post and from the IRLock forum as you was asking for the ‘hacked’ driver multiple times over the following weeks.

The other issues you mention I can see them, esp RC5-7.

Edit: Updated sentence to clarify

igor.vereninov · October 31, 2016, 8:20am

Corrado,

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.

Corrado_Steri · October 31, 2016, 9:06am

That is exactly what i mean, before “new exciting features” would be much better to support directly with update RC5…7 and all hardware shown in the ardupilot Docs. But i see you think differently.

No prob.

Corrado