Deploying camApp from Qt Creator

M

Matom

New member
Hi, I am using Chronos 1.4 for a research project and so far I am very happy with it. I need to make some changes to the software for it to function ideally for my project.

Is anyone here able to deploy a modified version of the camApp from Qt and use the camera afterwards? If so, can we share experiences?

I have installed the Qt creator following the README guide on github. Everything seems to be working and I am not getting any error messages. So far, I have not made any significant changes to the app before deploying it (I have simply changed the spelling on the main ui, just to see if it works), but I cannot use the camera with the ?new? version of the App.

I am working on Ubuntu 16.04 and the Qt creator is version 3.5.1.
 
What do you mean by "cannot use"? Does the screen display the main menu? Is the video always just black?
 
When I have Qt open and deploy the app, the camera turns on but the video freezes if I click anything on the display. If I exit Qt and turn on the camera (with the new camera app moved to the /opt/camera folder) there is just a black screen, no display or anything.
 
Hi Matom,

What version did you check out from Github, and what version of software is installed on your camera? There may be a conflict if you've built the wrong software version for the FPGA version on the camera.

David
 
Hi David,

Thank you for the answer. After updating the software to the newest beta version the problem was solved. Not immediately though. When the exposure trigger was on the image froze, so I assumed that it was still a problem with the FPGA version. However, by unclicking the exposure trigger I can now update the software and use the camera afterwards. Thanks!

Btw, I am searching for the part of the code that holds the image (and sends it from the ccd to the screen). So far I assume that the buffer (pbuffer) in the video.cpp script holds the image. Am I on the right path? Where is the easiest place in the code to access the image?

 
Hi Matom,

A frozen image is expected with exposure trigger enabled, no images will be taken unless a source drives the external input when in that mode.

Getting an image is a little bit of work, the video is all handled by an external framework called OMX (OpenMax), there are calls that allow you to get a buffer containing video data, but I'm not too familiar with them. Foobar may be able to comment more on that.

Are you looking to get raw image sensor data or processed 8bpp data?

David
 
Yes, thank you :)

I am looking for the raw image sensor data. I think I found it. However, I still did not manage to open and view the image that I dumped.
I dumped the values contained in the buffer from the "VIL_ClientCbFilledBufferDone" function.

The goal is to do a different video processing cycle than the one currently on the camera.
Because the camera will be working autonomously I don't need the image to be displayed.
 
I talked to Foobar, there's no easy way to get the live images from the OMX pipeline that's used for live display. It may be easier to use the Gstreamer pipeline that's used for saving, check videoRecord.cpp. Both of these video frameworks have quite a steep learning curve. If you're not using the LCD that makes things easier. It should be possible to spin up Gstreamer instead of OMX in live display mode.

To get RAW image sensor data you need to configure the video pipeline differently, see the routines for setting up for RAW saving, also in videoRecord.cpp.

You could also get recorded frames, albiet slowly, using the GPMC access used for black cal. Take a look at the black cal functions to see how this works.

David
 
Dear David,

Thanks for your answer. I spent the last few weeks trying to understand how the pipelines work. And I agree that the learning curve is quite steep ;) I have the live image (8 bit/per pixel version) from the OMX pipeline now. So far, I did not manage to configure the Gstreamer pipeline.

Do you have a flowchart of the software? It would be a great help to see how the pipelines are connected and how the image is transported from the sensor to the screen.
 
And I  have another question.

Does anyone know what the address of trigger 1 is? I am wondering if it is part of the FPGA code?
I would like to trigger it from the software instead of with an external voltage.

Any help would be very appreciated! :)
 
Hi Matom,

Sorry, forgot about the block diagram, I need to draw that up still.

Trigger is controlled by the FPGA, the all the trigger inputs are optionally inverted, debounced, then masked, then OR'd together before feeding the trigger delay unit. A register is also OR'd into this for software activation of the trigger, which is not currently used in the software, but does work.

The addresses of interest are
TRIG_ENABLE_ADDR - 3-bits, selects enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3
TRIG_INVERT_ADDR - 3-bits, selects invert enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3
TRIG_DEBOUNCE_ADDR - 3-bits, selects debounce enable (1=enabled) for each trigger source: Bit 0 - IO 1, Bit 1 - IO 2, Bit 3 - Input 3

SEQ_CTL_ADDR, bit 0 (SEQ_CTL_SW_TRIG_MASK) is the software trigger bit, writing a 1 is like making one of the trigger inputs active. Be careful you don't clobber any of the other bits when changing this, use a read-modify-write.

Here's an example of creating a trigger from software:

UInt32 reg = camera->gpmc->read32(SEQ_CTL_ADDR);
camera->gpmc->write32(SEQ_CTL_ADDR, reg | SEQ_CTL_SW_TRIG_MASK);
camera->gpmc->write32(SEQ_CTL_ADDR, reg & ~SEQ_CTL_SW_TRIG_MASK);

Let me know if this helps.

David
 
Dear David,

Thank you very much, it helped a lot! We now have a functioning internal trigger :D
Don't worry about the diagram. It would still be very useful, but we can manage without.

Ideally I would like to turn of the screen, video and everything. Is there an easy way to do that?

Maja
 
Dear David and the rest of Krontech,

I am sorry to keep bothering you about the SW. I am very close to my goal of making an internal trigger that stops the recording if a sudden burst of light appears. I just need a few more suggestions and maybe you can help. (Right now my trigger algorithm slows down the camApp, so it only processes something like 50 fps)

It is my understanding that the camApp runs three parallel threads. Is it possible to shut down one or two of them in order to save processing time? And how would this be done?

Is it possible to turn of the display? Either by using a specific function or by removing all the functions that make the image for the display?

Do you have other suggestions that would save me processing time? 

Maja
 
Hm, I don't think you're going to get more than a couple percent by shutting down the additional threads. I think they're pretty light. I think the display doesn't actually eat any appreciable processing power either, if you're not interacting with it. :-\

I myself would be tempted to look at algorithmic improvements. Sampling fewer pixels, or sampling less often, that sort of thing. I don't know how you've implemented the light detection, though, or really what the bottleneck is there. (I mostly do graphical design work.)

I almost wonder if an led with some sort of amplifier circuit could work as a pluggable trigger. I'm pretty sure one could be constructed for a few bucks in parts, according to the Instructable I found. I don't know your specific use-case though so I can't really offer much usable advice on that front, I think. If you had something else, another camera say, with a light sensor and the ability to output a trigger signal, you could use that as well.

As a side note, sudden light-level changes would probably be a great thing for us to be able to trigger on in general. Sound too. It's theoretically possible? It would be very nice to have built-in.


Whatever happens, best of luck Maja!
 
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.
 
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.
 
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 !
 
You must log in or register to reply here.

Similar threads

S
  • Sticky
🚀 Software Update 1.7.0 for Chronos 4K12 is Here!
Replies
0
Views
541
SHA
S
M
Lighthttpd Crashes
Replies
6
Views
589
mattD
M
M
Network speed issue ?
Replies
7
Views
441
PabloC
PabloC
K
Analog input support
Replies
3
Views
1K
kaklik
K
L
getting frustrated trying to figure out how to get a good picture
2
Replies
25
Views
2K
leonpiper
L
Back
Top