Currawong ESC troubleshooting (Duplicate Nodes)

Hardware CAN Devices
1

Anyone here had much success with Currawong ESC’s running on Arduplane, Im finding a lot of bugs and undocumented features!

Prime issue at the moment is erroneous duplicate node IDs in DroneCAN mode being reported in PreArm checks, that are intermittent, its like the Node database its referencing is actually referencing hardware IDs (or another feild, possibly a piccolo one?), but if you wait a few seconds it all works again and will arm… then a few seconds later it wont.

Have gone blue in the face troubleshooting and swearing, I suspect there is a numerous bugs making it difficult to nail down.

Anyone got this to work successfully?

To help with troubleshooting we have Servo 9 through 12 assigned as VTOL motors on quadplane. ESC ID is set 9-12 and we get working motors. Have tried all kinds of combinations of static node IDs, 9/10/11/12 and 19/20/21/22 and 29/30/31/32 etc etc, have switch from bus 1 to bus 2, the node ID conflict in its intermittentness is constant :slight_smile: . ESC telemetry is also intermittent, sometimes we get all 4 in logs, sometimes 1, control of the ESCs (once armed) seems solid, however.

I have had no luck in getting Piccolo CAN to work by the way, the ESC’s/Ardupilot are missing the field with assigns them to a motor/servo channel to respond to, the Piccolo equivalent of esc_index.

Error is very similar to this - https://github.com/ArduPilot/ardupilot/issues/15477

However, flashing the cube orange to rover and then back to plane (in attempt to clear node ID storage) does not solve it, even taking a NIB Orange and flashing it then plugging in an ESC results in the Duplicate Node ID error.

CANBus wiring is correct (its all twisted pairs), and correctly terminated, and passes termination checks successfully.

2

This is my worn out catch-all phrase for all CAN related issues…
Have you got:
BRD_BOOT_DELAY,3000
so CAN devices can boot up first and be ready for the flight controller to discover and assign IDs

and something like
CAN_D1_PROTOCOL,4

Otherwise it might be an issue for Tridge.

1 Like
3

Its definitely not boot up time, the ESCs are on very separate power system and can be booted minutes before the FC. Have gone blue in the face troubleshooting… (days now of having “what ifs” and then proving them wrong, hence why I suspect there are multiple issues). Just discovered the options bitmask for clearing/ignoring the node ID database, it might bandaid the situation.

4

Any thoughts @tridge ?

5

@JacksonUAS a duplicate node ID report means that the same node ID is appearing on the bus with 2 different unique ID identifiers. The unique_id is a 16 byte value that the a node sends in its NodeInfo response. For example, here is one from a Holybro compass:
image
ArduPilot keeps a database mapping between 7 bit node IDs and 128 bit unique IDs inside the DNA server. The DNA server also periodically asks for each node ID to give its NodeInfo. If it gets back a different unique ID then it may be that a node has been replaced on the bus by a different piece of hardware with the same node ID.
Given your description of the issue I suspect Currawong may have a bug where they don’t fill in all the bytes in the unique ID consistently for a particular ESC. For example, a STM32 CPU has a 12 byte unique ID, so in ArduPilot we fill in the first 12 bytes of the unique ID with the STM32 ID then pad with 4 zero bytes (that is why you see 4 zeros at the end in the example above). Maybe Currawong is not padding with zeros correctly?
The workaround of setting the CAN_Dx_UC_OPTIONS bit to ignore the duplicate IDs is almost certainly the correct workaround for you, but you should ask Currawong to look into this and put out a firmware update to fix the issue.
I have emailed Oliver from Currawong a link to this post.

2 Likes
6

For reference of anyone finding this post:

I have had no luck in getting Piccolo CAN to work by the way, the ESC’s/Ardupilot are missing the field with assigns them to a motor/servo channel to respond to, the Piccolo equivalent of esc_index.

When running under PiccoloCAN the “Node ID” of the ESC must be set to the “Motor Channel”. The PiccoloCAN protocol does not make a distinction between ESC ID and Motor ID.

1 Like
7

More details - clearing the Ardupilot DNA cache resolved the issue.

8

Cheers Oliver can confirm the above, and to future people who find this -

Piccolo -

CAN Node needs to align to motor number, servo channel set in ardupilot is irrelevant
ESC Telemetry is provided under esc number (motor number) .

example -
Node 1 = Motor 1 = ESC Telem 1 = Servo x

DroneCAN -

CAN Node ID is irrelevant. ESC index message in DroneCAN needs to align to servo channel associated to the motor number. ESC telemetry is provided as ESC whatever is set to servo channel

example -
Motor 1 = Servo x = ESC Index x = ESC Telem x

So if servo 9 is motor 1, x is 9.

9

Is anyone else having this issue when using DroneCAN on Currawong ESCs? Does clearing the DNA Caches once wholly resolve, or do you have to do it frequently?