Skip to content
This repository was archived by the owner on Aug 22, 2024. It is now read-only.
This repository was archived by the owner on Aug 22, 2024. It is now read-only.

Arduino external sync acting as Master produces unexpected capture behaviour with two devices in Subordinate mode #1780

Open
@CharliPosner

Description

@CharliPosner

DESCRIBE THE BUG

We are trying to use an Arduino Uno external sync as a Master device, controlling the captures of two Subordinate AK sensors with the latest firmware. We have programmed the Arduino to emit interlaced, periodic pulses, emulating Sync Out capture pulses, out of two separate pins, and have wired these pins to aux cables plugged into the AK devices via Sync In.
When testing to see if the captures were behaving as expected, we also programmed the Arduino to control two LEDs, such that one LED was always high at any time. The LED is set to turn on at the rising edge of the capture pulse of the first Kinect, and turn off at the rising edge of the subsequent capture pulse controlling the other Kinect, and vice versa.
The expected behaviour was that each AK would be triggered to capture when it received its pulse from the Sync In port, and therefore would also capture its respective LED being lit up. In turn, when the second AK captures, in the delay period of the first AK, the second LED was expected to be lit up. In reality, it appeared that the same LED was bright for both AK captures, indicating that they are happening either at the same time or in quick succession, which contradicts the input signal being fed to it. In addition, when we unplugged the Sync In from one AK and plugged that same signal into the other AK, instead of showing the same LED being lit up (as would be expected), the opposite LED was shown to be lit up. We also noticed that when holding both Kinects, and moving them with the LEDs still in view, there was occasional flickering between which LED was lit up and which was dim. This indicates that the capture rate is unstable and that the AK is not listening to the input signal when timing its captures. This shows unexpected timing behaviour of the AK when used with an external trigger and no Master device.
As a further experiment, we tried assigning one AK as the Master and one as Subordinate, with a normal aux cable between their respective Sync Out and Sync In, and programmed the k4aviewer 'delay off master' to the time period between 60fps captures. This also resulted in similar behaviour - both AKs only captured the same LED as high.

TO REPRODUCE

  1. Set up PC and AKs according to Desktop information below
  2. Program an Arduino to produce interlaced, periodic, active-high pulses of 5V, 10us time periods, such that the time between pulses is around 16.7ms (1/60Hz). We tested with an oscilloscope to ensure accurate timing and minimal cross-channel ringing

Arduino code:
`// 60 FPS interlaced
void loop() {
PORTD |= 1<<LED_1; // LED_1 high
PORTD |= 1<<PIN_1; // PIN_1 high (the delay introduced by this instruction is only one cycle for a 8 MHz clock in the UNO)
_delay_us(10); // capture pulse must be 8-14us
PORTD &= ~(1<<PIN_1); // PIN_1 low
_delay_us(16000); // total capture period calculated as 1/60Hz
_delay_us(652);
PORTD &= ~(1<<LED_1); // LED_1 low

PORTB |= 1<<LED_2; // LED_2 high
PORTB |= 1<<PIN_2; // PIN_2 high
_delay_us(10);
PORTB &= ~(1<<PIN_2); // PIN_2 low
_delay_us(16000);
//_delay_us(652);
_delay_us(465); // lower delay value here to account for delay in system
PORTB &= ~(1<<LED_2); // LED_2 low
}`

Oscilloscope reading (input capture signals to AKs):
image

  1. Cut an aux cable in half, separate out the wires. Using a breadboard, connect the signal wires of the aux to the signals from the Arduino, and the ground wires of the aux to the grounds of the Arduino. For our setup, each piece of aux cable was just under 1m long.

  2. Place two red LEDs on the breadboard, in series with resistors, and connect them to the LED-programmed pins of the Arduino respectively

Physical circuit:
(Note: the ceramic resistors were used as wires for obtaining oscilloscope readings)
github_setup

  1. Open two instances of k4aviewer on the PC connected to the AKs, and place the AKs such that both LEDs are in full view for both sensors. Configure both viewers to 1536p, NFOV Unbinned, 500us manual exposure, 30fps, imu OFF, external sync = Subordinate. The viewers will wait for the master signal from the Arduino to start
  2. Plug in the Arduino power, and assess the captures of each AK and its respective LED

k4aviewer output stream:
The images below are of LED_1 being covered, then LED_2 being covered. They show that both AKs are seeing the same LED being lit up, despite receiving different capture signals.
Screenshot from 2022-05-17 12-06-48
Screenshot from 2022-05-17 12-06-53

  1. Pick up and move the AK devices, keeping the LEDs in frame. We observed a change in which LED was lit up when moving the AKs. Also remove the Sync In cables from each AK and switch them around. Both AKs will have the same LED lit up when both Sync Ins are swapped, showing that the Sync In cables are giving the opposite outcome for each AK, with the same signal.

EXPECTED BEHAVIOUR

  • The AKs capture at 30fps each, but the interlacing of the captures results in an effective 60fps capture rate of the system
  • Each AK only sees its corresponding LED as high, as both the AK capture and the LED brightness are controlled by the same signal
  • Unplugging the Sync In cable from AK1 into AK2 should result in AK2 seeing the same LED as high as AK1. This is because its capture period should mimic the signal coming into its Sync In port
  • Moving the AK devices does not affect which LED is lit up and which is dim, as the capture rate is set by Sync In

DESKTOP INFORMATION

  • Ubuntu: 18.04
  • SDK Version: 1.4.1
  • Firmware version: AzureKinectDK_Fw_1.6.110079014.bin

Metadata

Metadata

Assignees

Labels

BugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions