Deploying camApp from Qt Creator

[Matom]

Thank you for the input The display would be nice to turn of anyway, to avoid light leakage (we will shoot in a very dark environment). Is it possible?

And yes, I am currently trying to improve the algorithm, however it still cannot trigger on light pulses that are shorter than 50 ms.

Regarding an external led or camera as trigger, this is our plan B, but ideally everything should be internal in the Chronos.

Yes, in our research (lightning) such a trigger would be a great addition. If I manage to develop something that works, I will be happy to share ideas with you.

[BiduleOhm]

Why not a hardware trigger? Just a few components would do the trick.

[Matom]

Hi BiduleOhm,

What type of hardware trigger are you thinking of? A photodiode?

We will use the camera remotely (from a different country) and therefore want to avoid as many additional part as possible. With a software trigger we can easily adjust it from home with remote desktop. In addition we want to be sure that the camera only triggers on the right type of events and events that are luminous enough for the Chronos' sensitivity.

These are the main reasons for an internal software trigger. However, I am very happy to get advice and new ideas.

[BiduleOhm]

Yep; photodiode, phototransistor, LDR, CDS, ...

But yeah, given your use case it's best if it's in software

[Matom]

Hi Again

After updating my computer (and restoring the camera because it wouldn't boot), QT is deploying the camApp that I'm working on directly to the /opt/camera folder. This seems to cause a lot of problems for me and I have had to restore the camera several times. The qt folder that the modified camApp was normally deployed to is gone. I have tried to make a directory myself and use it as working directory in QT but it doesn't work. Do you have any suggestions? How should QT be configured to make sure that I don't overwrite the original version of the camApp?

Thanks in advance !

[tesla500]

I would recommend leaving camApp running out of /opt/camera, and just back up the original camApp (rename it something else, then rename it back later). Otherwise, in the QT creator Run Configuration, you can change the deploy path. As long as the working directory is set to /opt/camera, it will find the calibration files, the application can be run from any location. Let me know if this works.

David

[Matom]

Thank you David, I just backed up the original app, and so far there are  no problems.

[Matom]

Dear David,

I am starting to get problems that I did't have before. I have had to restore the microSD card 3 times within a week (when I was working out of the qt folder before, this only happened 1 time in 3 months). It happens when I work in Qt for a while and keep updating the camApp. Once in a while a connection error happens and I can't access the camera with ssh or Qt and a hard reboot is the only option. However the reboot can't open the camApp, so I have to restore the SD card. Is there a way to avoid this? If not, I can live with it, because I am almost done with the trigger.

However, I have another question:
There is a big difference between the CPU time and the real time of my trigger function i video.cpp. My guess is that there is a frame-rate set or delay/sleep/wait somewhere in the code that limits the frame-rate. Where is this?  I have changed the definition of MAX_LIVE_FRAMERATE in camera.h but this does not change it.

Thank you in advance, Maja.

[tesla500]

Hi Maja,

You might try going back to the QT folder but leaving the working directory as /opt /camera, or potentially going back to the old way but copying the calibration data into the required position. Another option to try is to remove the script that starts the camApp on bootup, which should be in /etc /init.d /, I believe it's just called camera.

Generally, if you use a breakpoint, the video system will become unhappy and require a restart, is it possible that is causing your crash? The debug version of the application may they not properly restart when you restart the camera, leading to the issues you're seeing.

In regards to your second question, could you describe the timings you are seeing, what specifically you're measuring? There is a delay of about 6-8 frames from image capture until the frames get displayed on the LCD, is this what you're seeing?

David

[Matom]

Dear David,

Thank you,  I'll try that.

I'm working in the VIL_ClientCbFilledBufferDone function. Here I do a bit of image analysis on each buffer, before it is passed on in the code. My algorithm is very light and is not the limiting factor when is comes to processing time. I have timed the function using clock() and time() and I can see that the CPU time (from clock()) is much lower (8 seconds to process 1000 frames) than the actual time (16 seconds for 1000 frames). The 16 seconds make me think that there is a value of 60 fps set somewhere in the code, maybe because the buffer is used display on the LCD. I don't use the display, but just want as many frames as possible to be processed in order to catch events of a few ms duration. I hope this makes sense

Cheers,
Maja

[Matom]

I also timed the routine without including my algorithm and in this case the cpu-time was around 2 seconds for 1000 frames, whereas the real time was still 16 seconds. Therefore, I think that there must be a delay or a set frame-rate somewhere. Maybe in the OMX files? I just can't seem to find the one that does the trick.

[DDR]

Im running Windows 10 and using Qt Creator. I installed Qt 5.8.0.

Hi Michael, I'm afraid Windows 10 is not a supported development platform. In addition, Qt 5.8.0 will not run on the Arago linux, the operating system of the camera.

Your best bet is to install Ubuntu in a VM such as VirtualBox and modify the existing QT 4 camapp, as per these instructions.

We have a version of the camera running Debian that can compile for itself, but I do not currently have video capture working on it. That will be brought together after my colleagues return from DEF CON, and hopefully documented not long after.

Best of luck!