Holybro RemoteID trouble/does not work without ArduPilot-ODID custom FW

Bought four Holybro RemoteID’s.
The devices look good, and that’s about it.
Solid red light.
Followed instruction on Setup & Configuration - Holybro Docs
The instructions are suboptimal, as they do not ensure CAN os enabled, but do mess with GNSS type.
Regardless of being connected to serial or CAN, I can not see any parameters.
I did email Holybro support, but did not got any reply yet.
I start to wonder if there is any firmware on them.

You need to use the Drone CAN GUI tool software to set them up instead of mission planner. And they need to be connected on. Can1. Can2 will not work. And yes, they are lacking documentation.

But they do work once configured properly

@amilcarlucas thank you, I guess you mean:

or …something on https://opencyphal.org ?

I can’t even imagine why it would not be able to work on CAN2 :slight_smile:

I mean Drone CAN GUI tool.

I loaded it and tried to connect to the cube with the RemoteID on CAN1

But I fail to see/find any device;

I have also set CAN_SLCAN_CPORT = 1 and SERIAL5_PROTOCOL=22
The HolyBro support failed to help, after finally answering, they responded as if I was asking how to compile firmware, no information on upload or first connection.

Have you activated CAN1 in ArduPilot parameters?

AC 4.4.4
param show CAN*
STABILIZE> CAN_D1_PROTOCOL 1 # DroneCAN
CAN_D1_UC_ESC_BM 0 #
CAN_D1_UC_ESC_OF 0
CAN_D1_UC_NODE 10
CAN_D1_UC_NTF_RT 20
CAN_D1_UC_OPTION 0 #
CAN_D1_UC_POOL 8192
CAN_D1_UC_SRV_BM 0 #
CAN_D1_UC_SRV_RT 50
CAN_D2_PROTOCOL 1 # DroneCAN
CAN_LOGLEVEL 0 # Log None
CAN_P1_BITRATE 1000000
CAN_P1_DRIVER 1 # First driver
CAN_P2_DRIVER 0 # Disabled
CAN_SLCAN_CPORT 1 # First interface
CAN_SLCAN_SDELAY 1
CAN_SLCAN_SERNUM -1 # Disabled
CAN_SLCAN_TIMOUT 0
SERIAL5_PROTOCOL=22

  • I am connecting the the CubeBlacks’s USB port - the RemoteID is connected to CAN1 on the carrier.

Check the cables. Do you have REMOTE ID enabled ArduCopter FW?

Cables are the original JST-GH 4p CAN cable, - and tried with more than one of the four RmoteID’s I bought.

This is Arducopter 4.4.4 /current release. By “remote-id enabled” , you mean anything since Copter 4.2.3.
I am not aware of any parameter that needs to be enabled for it to work.

You need to compile or use “remote-id enabled” Firmware. The “normal” FW has no remote ID support.

You really, really need to read the remote ID documentation

Oh, I have read that link… too many times. Not finding any clear instructions.
Fumbling around - I discovered that CAN1 apparently is “bus number 2” - once I set but number two I see:

RemoteID is apparently supported in stable firmware since 4.2.3 are you sure about the need for some specific firmware?

Yes, I am sure. I have flown a working Holybro Remote ID already. Have you seen the video once?

It clearly states that you need special FW.

A while ago, I saw that video, then more, recently I read the release notes https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L1018C29-L1018C38

and I thought the video was outdated/not applicable especially as it had much focus on the ESP32 part too, which again… reminded of the early days of the RemoteID mess. And I was blissfully ignorant of this still being the situation.

I still fail to understand why this is an optional build as I see it, the RemoteID thingy could just receive position(s) via MAVLink (or CAN) - and be configured with operatorID and other stuff itself, so that it would not require any special firmware in the autopilot.
I did not expect to compile new FW for all our UAV’s just to get this stuff to work. (with the slight risk of some toolchain cockup)

We are still very much here. It’s a sh*t show.

Correct me if I’m wrong, Amilcar, but I think the reason for not including this by default has to do with the tamper proofing requirement, which makes it very difficult to include as a standard feature.

Andre, you might be interested in a fully standalone product that requires only power to broadcast RemoteID.

well, after having tested this… this is not for me.
We need something closer to the “standalone” solutions.
I imagined something that took the takeoff position, as GCS position if GCS pos. not available.
Something that just uses telemetry to get position/altitude.

NOT:
something that is overly complex, requires custom build, and sabotages operation if GCS is not of a certain type. Ultimately, the current state almost requires MissionPlanner to work, and I would not involve MP and especially windows in any serious operations. (and it runs even worse on Linux)

I see this as an attempt to live up to crazy regulations, but having permission to fly self-built UAV’s makes it insane to jump thru more hoops in order to strive to “prevent” us from taking off w/o this system - which we first install.

Wish for a “best effort” version, that just needs MAVlink, (pos/altitude and frame type?) and is willing to use takeoff pos as pilot pos if not provided by GCS, not stopping flights.