False CAM feedback 5ms after first TRIG signal

Ok, thanks!
If it is systematic it is easy to filter it out.
However, I am currently not receiving any CAM messages any more if CAM_FEEDBACK_PIN > -1 (55 in my case). Even the one after the first TRIG log is gone…
This is really strange. I made no adjustments to any parameters. Already, changed SD card and checked parameters several times. Unfortunatly, I do not have any voltage meter with me to test the feedback cable…
I’ll keep testing…

Hm… no matter which firmware I only get CAM messages if CAM_FEEDBACK_PIN = -1.
It was definitely working before with CAM_FEEDBACK_PIN = 55 - and I always had this inital CAM message after the first trigger. I am a little lost here. Need a circuit indicator before any further tests.

Marking it as solved until I am sure about the CHDK LED feedback cable.

I can’t get it running again. Still only TRIG messages.
Since triggering using relay works if I set CAM_FEEDBACK_PIN to -1 it can only be the Feedback settings and/or the feedback cable.

Is there anything important apart from these two parameters?
CAM_FEEDBACK_PIN 55
CAM_FEEDBACK_POL 1
On Pixracer I am using PIN 54 the trigger pin with BRD_PWM_COUNT set to 4.

Am I right that when I simply short cut “S” and “-” on PIN 55, I should see a CAM entry in the log? If so, it does not work. I tried to manually without the cable with no success. It did work this morning with my cable…
Also, why is the false CAM message now missing as well?

Any suggestion what to test?

@WickedShell help, please :slight_smile:

Regarding the orginal topic, the initial wrong CAM message is a known bug. (But the resolution/source of it is still unknown).

For shorting the pin to ground to work you need something that will pull the pin back up to +3.3V or there won’t ever be a second transition on the line. Still, you normally would see enough noise from a floating signal to prove that it was or wasn’t transitioning. If you have one on hand I’d highly recommend clamping a logic analyzer on the pin, or using a LED inline with the shorting mechnaism to prove that the signal is making it to the pixhawk correctly.

I assume from your comments that you are trying to take a photo before looking for the CAM event? (We only configure feedback after the first trigger, and we only search for a single feedback event to tie to the trigger. I’m fairly sure this isn’t the problem you are actually having however.

Do you have any other device trying to use the pin? (RC_FUNCTION (or SERVO_FUNCTION’s depending upon firmware) any other RELAY’s/parachutes/etc using the same pin?

What FW image is this?

@WickedShell and @OXINARF,
thanks a lot for your help and suggestions!

Yes, I am using the CH7 option for these tests.

No, it is a Pixracer QUAD. So I only have these to pins available and nothing else connected or set.

My initial successful tests were on AC3.6dev - shortly after AC3.5rc3. Curreltyly, I am switching between AC3.4.6 and AC3.5rc4. Since both do not work properly I think it is not related to any recent changes.


I made some further interesting tests:

I installed rover to clean all settings and installed AC3.4.6 again with a freshly formatted SD card. The I
only set the camera trigger and feedback params. Still the same - only TRIG messages no more CAM messages if the Feedback pin is set to 55. I assume it is either a logging (see related discussion at: Bad Logging / LOG_DISARMED = 1 / no CAM/TRIGG logs) or some hardware issue. I checked all connections and everything seems fine.

Since I am out of office, without any further equipement and copters with me, I cant run any further reasonable tests until next week.

Side note: While desparately playing with some settings I managed to “brick” the Pixracer… Not really related but you might be interested as well:

I tried different cluster sizes when formatting the SD card and set it to 64kb. On AC3.4.6 I also set the logging buffer to that size. Logging while disarmed was enabled. This resulted in:

PX4v4 002E003F 3235510B 32393433
Frame: QUAD
PX4: de6b667d NuttX: 8c965992
APM:Copter V3.4.6 (e707341b)
GPS 0: detected as u-blox at 115200 baud
NavEKF2: not enough memory

Switching back to 3.5rc4 resulted in Mission Planner reporting an unexpected error. I was unable to connect to the PixRacer and Windows 10 detected some problems with the card as well. But it was working fine under Windows before. So it may be a NuttX thing and something got corrupted. Reformatting the card with the same settings under Windows did not solve the connection issue. Formatting the card with 4KB did not solve the issue as well. I still was not able to connect. After some attempts I was able to install plane and then AC3.5 again.

Back to the default logging buffer and cluster values I still do not get CAM messages but - interestingly - duplicated TRIG messages:

TRIG, 50297836, 468572800, 1944, 50.3646788, 8.8669684, 0.46, 0.46, 126.44, 3.86, -4.97, 179.82
TRIG, 50301060, 468572800, 1944, 50.3646788, 8.8669684, 0.46, 0.46, 126.44, 3.87, -4.97, 179.82

Will stop here and make further tests on another board next week.

Thanks a lot!
Cheers,
Thorsten

Will a CAM event be recorded with intervallometer shooting of the camera or does it need a TRIG command before ?

@lucamax
what is required to record the CAM event is a connection between the autopilot and the camera. If the autopilot triggers the camera (based on a survey mission) the event is logged in the ardupilot dataflash log file in the CAM message. If there is some feedback from the camera when it takes the picture (hot shoe feedback) the trigger event is stored as a “TRIG” message and the feedback event is stored in the CAM message. If you use an intervallometer there is normally no connection. You find details at: http://ardupilot.org/copter/docs/common-cameras-and-gimbals.html#camera-shutter-triggering

Thanks Thorsten ,
so even if a hot shoe connection with digital input on the Pixhawk exist, if the camera shoots with intervallometer there will be no event recorded in Pixhawk logs ?

It could be a good idea to allow it IMO, a lot of people use intervallometer in aerial mapping.

@lucamax
not sure about that. From what @WickedShell said it seems it is not working thisway.

But good idea!

@lucamax: Correct

@Thorsten you can clear all the parameters by changing the FORMAT_VERSION number and power cycling. (This is the internal format description of the parameter table, if it’s ever off we have to clear and recreate the table).

The dataflash related parts of that are unfortunately out of my experience, @peterbarker or @OXINARF will be more helpful there.

I’ve seen duplicated TRIG’s before when triggering with MP, but you indicated you are triggering with CH7 options (also something I’ve never played with). I suspect the core problem isn’t a logging one, because if it was you shouldn’t be seeing the TRIG messages. My bet would be on a hardware or software related bug. I’d recommend the first step as being getting a probe on the setup and verifying that the expected signal is arriving at the pin.

@WickedShell
thanks for your reply! The good news for me is that you have seen it before :wink: I am pretty sure to have a clean setup. I’ll be back on Tuesday and can run further tests on other copters and with more equipement at hand.

Ok, during my last tests I tried both triggering with MP and CH7. So these duplicated TRIGs might come from MP. But what should be the difference between MP and CH7?

IIRC there are actually two different MAVLink messages that can trigger a camera, MP isn’t sure which one is supported by the autopilot so it covers its bases and sends both versions. (One of them is considered deprecated, but because you might be using MP with an older firmware image it still sends the old one).

OK! Will check, but I am pretty sure it was AC3.5rc4 with the latest version of MP.

MP:

1.3.46 build 1.1.6309.37214

AC:

 MSG, 9382203, APM:Copter V3.5.0-rc4 (bd6acd96)
 MSG, 9382220, PX4: 47909b0f NuttX: be6ff61a
 MSG, 9382266, PX4v4 002E003F 3235510B 32393433

 TRIG, 32362901, 468555000, 1944, 50.364689, 8.8669454, 0.48, 0.48, 121.35, 3.83, -4.97, 179.65
 TRIG, 32365801, 468555000, 1944, 50.364689, 8.8669454, 0.48, 0.48, 121.35, 3.83, -4.97, 179.65

If you were to dump the tlog, what I think you would see is you get 2 camera related messages sent one after another to the autopilot. (I forget the exact message names at the moment). Dual trigs are expected in that situation, it would only result in one photo however.

OK, that’s good to know! Thanks! I have no problems with duplicated TRIGs or a duplicated CAM in the beginning - all fine as long as it is a systematic behaviour.
Just need to figure out now why I do not see any CAM messages anymore after a TRIG. I’ll report…

Hi @WickedShell and @OXINARF ,

I made some further tests comparing an original Pixhawk and two Pixracers running AC3.5rc4.
On the Pixhawk it works as expected but not on the Pixracers. I do not get a CAM message/feedback on the Pixracers.
The parameters are identical except BRD_TYPE. I also used the same SD card. So it must be either some parameter setting or some firmware issue regarding PX4v4, which then must have been introduced between rc3 and rc4, because I had it working on the Pixracer with a dev version from shortly after rc3.

As described above I am using the following settings:

CAM_FEEDBACK_PIN 55
CAM_FEEDBACK_POL 1
On Pixracer I am using PIN 54 as the trigger pin with BRD_PWM_COUNT set to 4.

I tried setting Relay 2 to 55 but no difference to -1.
Is there other parameter that is related?

In this test I used Mission Planner to trigger the camera not Ch7. PIN 54 was not used since no camera was connected. I triggered the feedback manually using my simple CHKD LED phototransistor cable and the savety switch LED… Maybe it is an electronical thing regarding the trigger cable. But since it was working before I doubt it.

Any suggestion for further tests are greatly appreciated :slight_smile:

Thanks a lot in advance and best regards,
Thorsten

1 Like

This was the “setup” for the test:

I have an idea what might have happend to your Pixracer. In contrast to the classic Pixhawk, the racer does not have any level shifters/buffers on the servo header pins. Instead, the MCU pins are directly exposed. There isn’t even a protective resistor in series with the pin, which can be considered a design flaw IMHO. If you pull that pin to 5V hard enough, there is a very good chance to instantly kill the STM32 or at least that pin. Even shorting it to GND might be dangerous while the pin is still configured as output.

Here is what I did:

This solutions seems to work quite well with 3.6-dev. No spurious CAM messages and the PixRacer seems to be still alive after a few hundred trigger actions. I soldered the diodes (BAT42) directly to the board, while the three resistors are part of the cable. The diodes might be not strictly necessary, but given the long wire usually connected to the pin, it just feels better :wink:

1 Like