KronTalk
Chronos => Software Dev => Topic started by: tesla500 on November 20, 2017, 09:46:27 PM
-
At long last, the Chronos Camera application source is now available at the following git repository:
chronos-cam-app (https://github.com/krontech/chronos-cam-app)
Currently we only support Ubuntu 16.04 LTS as a build environment. 17.04 is known to NOT work due to different compiler versions included. You're welcome to try other environments, please let us know what works and what doesn't.
Follow the instructions in the repository readme to set up your build environment.
We suggest not doing any significant changes or customization right now. We are in the process of breaking out the low level camera control into a daemon controlled over D-Bus. This will allow the cam app to talk to the camera seamlessly, whether local or operating remotely over a network connection. Ideally, the exact same application will be able to be compiled to run on the camera or on a PC.
Once you have the application compiling, you can connect to your camera over SSH. Plug the mini-USB port into your computer, and it will enumerate as a USB to Ethernet bridge (serial numbers 00050 and above, earlier cameras need an update, available here (http://forum.krontech.ca/index.php?topic=105.0)). You can then log into the camera using root/<no password>
I'm sure there will be many questions, please let us know any problems so we can provide better build instructions.
David
-
Holding in case more space is needed #1
-
Holding in case more space is needed #2
-
That's great news and looking forward to trying it. I'm on Mint 17 which is based on the ubiquitous Ubuntu 14.04 so will let the forum know if all good.
-
Great news! I have S/N 34 so will wait for the USB/ETH fix before I dive in.
-
Great news! I have S/N 34 so will wait for the USB/ETH fix before I dive in.
Update posted, see topic at:
http://forum.krontech.ca/index.php?topic=105.0
-
Thanks!
Did a quick attempt at building the QT framework and got stuck at the step where you "make" "make install".
I will figure it out, but ran out of time, this time.
-
Outstanding! Looking forward to playing around with it
-
Running the script conf.sh to setup the QT build generates an error. I tried to Google it, seems lots of people have fallen i this trap but failed to find a solution. I am sure it's fixable but also guess it will take a lot of time. Any chance you could update the readme with the steps required to build tslib for the Chronos apps processor or maybe even include the necessary files in the target rootfs so we don't have to build it.
The error ...
"The tslib functionality test failed!
You might need to modify the include and library search paths by editing
QMAKE_INCDIR and QMAKE_LIBDIR in
/home/davor/work/qt-everywhere-opensource-src-4.8.7/mkspecs/qws/linux-omap2-g++.
"
-
Hooking up the mini USB to a Linux machine to get an ETH interface works fine. The camera responds to ping.
But
"You can then log into the camera using root/<no password>"
user=root, password=<nothing just press enter>
Generates an "Access denied" response.
I am using Putty as my terminal program.
-
Running the script conf.sh to setup the QT build generates an error. I tried to Google it, seems lots of people have fallen i this trap but failed to find a solution. I am sure it's fixable but also guess it will take a lot of time. Any chance you could update the readme with the steps required to build tslib for the Chronos apps processor or maybe even include the necessary files in the target rootfs so we don't have to build it.
The error ...
"The tslib functionality test failed!
You might need to modify the include and library search paths by editing
QMAKE_INCDIR and QMAKE_LIBDIR in
/home/davor/work/qt-everywhere-opensource-src-4.8.7/mkspecs/qws/linux-omap2-g++.
"
I knew there was a step missing from the instructions! You need to put tslib.h in /usr/include in your targetfs directory. Using the paths shown in the instructions, that would be ~/Work/chronos-sdk/targetfs/usr/include. We forgot to include that on the filesystem shipped with the camera.
File is attached.
Hooking up the mini USB to a Linux machine to get an ETH interface works fine. The camera responds to ping.
But
"You can then log into the camera using root/<no password>"
user=root, password=<nothing just press enter>
Generates an "Access denied" response.
I am using Putty as my terminal program.
The camera uses an old version of SSH, and only supports a deprecated (insecure) key exchange algorithm. You need to use the following command to connect to the camera with SSH from modern systems:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]
-
Thank you.
QT builds fine now and I can connect to the camera via SSH.
Next obstacle.
When trying to build the Camera app in QT creator I get an error in video.h originating from line 42 where OMX_Types.h is included.
I can't find the file so I assume that is a legitimate error and not the usual path problem.
-
Thank you.
QT builds fine now and I can connect to the camera via SSH.
Next obstacle.
When trying to build the Camera app in QT creator I get an error in video.h originating from line 42 where OMX_Types.h is included.
I can't find the file so I assume that is a legitimate error and not the usual path problem.
You've copied the contents of the boot MicroSD card to the targetfs folder, right? There are some header files in there that are needed. Also, what OS are you using as your build host?
-
Yes I did copy the content of the SD card ROOTFS partion to the ...../targetfs/ folder.
Where on the SD card can I find the missing header files? I already looked in the most obvious places and did a search.
My host machine runs Ubuntu 16.04 LTS
-
Did you copy from the Linux EXT3 partition? I can make up a tar with the entire filesystem on it if needed.
-
As far as I can see the SD card has 2 partitions. One EXT3 with volume name "ROOTFS" and one called BOOT. I copied the content of the ROOTFS partition.
I assumed that all files might not have come across in the copy operation (tar the rootfs and then untar on host is the way it should be done but is normally only necessary if you want to use it as a NFS for the camera during development)
So when I look for the missing header files (OMX_Types.h is the first one reported as missing) I am looking both on the SD card and the copy on my host.
Delivering the file system as a tar ball will not help if the required files are not there. Based on your response it sounds like you know they are there. So where on the SD card can I find for example the "OMX_Types.h" file?
E.g. either we need to modify the project to remove that dependency or include the files.
-
I have those files in mine, we did change the SD card image after serial number 00049, I believe those older cameras may not have the include files on them. I've attached a tar with all the includes, extract it to /targetfs/usr/
Let me know if this works.
-
Thanks David, (getting replies from the main dev around Christmas is unheard of, so an extra thanks for that and Merry Christmas)
That's it!
Quick hack to remove the annoying warning message about unsaved data in RAM. Built the app and tested it on the camera.
Works as expected.
Now need to figure out a way to develop app and test without the SD card in and out copy. That works fine for a quick test but for any more advanced development I need either the camera to mount rootfs over NFS or a way to have the debugger load the executable directly to the camera.
Never used QT before but that looks fairly easy to learn. How do you develop/debug?
Best Regards
Davor
-
The README in the github repository has been updated with a description of how to get the debug environment working under Ubuntu 16.04. Unfortunately I haven't been able to get debugging working from anything newer (ie: Ubuntu 17.04 and beyond) due to some issues in newer versions in QT creator. There process is roughly broken down as:
- Install a cross debugger and configure the camera kit to use it.
- Add the Camera as a device in QT creator using SSH.
- Kill the camApp daemon via SSH to gracefully shutdown the video pipeline.
- Start your debug build of the camApp from QT creator.
SSH access to the Camera is provided through the mini-USB port labelled "OTG". When you connect your laptop to this port it will come up as a USB network adapter. The Camera has a static IP address on this interface of 192.168.12.1, and your laptop will get an IP address assigned to it via DHCP (this should be familiar if you've worked with Beaglebones before). By default there is no root password, and SSH will accept anything you type for a password until a password is configured.
-
Hi foobar, thanks for the update.
The deploy/debug part does not work.
- Setup device -> works fine and "test" shows.
Connecting to host...
Checking kernel version...
Linux 2.6.37+ armv7l
Checking if specified ports are available...
All specified ports are available.
Device test finished successfully.
-> Deploy/debug generates following error. (yes i did first kill the running camApp)
16:32:53: The process "/usr/bin/make" exited normally.
16:32:53: Unexpected output from remote process: "Available"
16:32:53: Deploy step failed.
Error while building/deploying project camApp (kit: Camera)
When executing step "Check for free disk space"
16:32:53: Elapsed time: 00:00.
PS.
As far as I can see the Ethernet port works fine and actually better than the USB/ETH connection. E.g. I can use WinSCP and Putty/ssh when camera is connected to my local network with ethernet cable. As you already explained that will not work with the USB/ETH.
I tried both ETH port & USB/ETH for the debug and the result is the same.
-
The failure in the Deploy step sounds very similar to some of the issues I encountered when trying to get QT creator working on Ubuntu 17.04, what I found was that newer versions of QT were getting some paths wrong and trying to find the free space of a directory that didn't exist on the target. Rather than trying to figure out why, I simply switched my development machine back to Ubuntu 16.04 LTS, which seemed to work just fine. Can you check which version of Ubuntu and QT creator you're using?
-
host = Ubuntu 16.04LTS. QT creator ver = 3.5.1.
In the .pro project file there is a target.path = /home/root/qt. that path does not exists so I fixed that by adding the qt folder.
That unfortunately did not help.
Googling the problem I found a post suggesting QT will try to load to /root.
So I created a /root folder, that did not work either.
Change install folder permission to rw access for everybody. Did not help.
Running out of ideas to try but I will continue ...
-
Try removing the Check for Free Space before deployment, I recall that not working. See screenshot of my Run configuration, see if yours is the same.
-
That was it.
Removed "check for free space" and changed path in .pro file to target.path = /opt/camera
Deploy/Debug works fine now.
Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.
Once it's working I will be happy to show what I have and share if anybody is interested.
-
Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.
Once it's working I will be happy to show what I have and share if anybody is interested.
We're also working on this, in fact pretty much all our effort now is devoted to getting Ethernet remote control and video download working. It's a very nontrivial task to just get the video into a RAM buffer, which is one of the reasons why it's taking so long.
The video system is built on a framework called OpenMax (OMX). Most of OMX is run internally by a separate M3 core in the CPU. This runs a binary blob provided by TI, the source is available from TI under an NDA, ask for the "DM8148 EZSDK Overlay Package". This handles pretty much everything related to video input, processing, and output to the display. There's another M3 running a different binary blob which operates the H264 encoder. We've modified the former M3 code somewhat to add features like the video save throttling.
In the camApp, OMX is used directly for live display, and saving is done using gstreamer. Internally, gstreamer uses OMX as OMX is the only way to do anything with the hardware accelerated video pipeline. There is currently a problem with the gstreamer component that allows you to get frames into a RAM buffer, foobar or Loial could comment further, but we believe that the component that provides RAM buffers doesn't properly handle shutting down the pipeline, which crashes the M3. This issue needs to be solved before we can get RAW saving over Etherent working.
gstreamer currently supports streaming compressed video via RTSP, if you just want live display that should be significantly easier than getting RAW.
Take a look at videoRecord.c to see how the gstreamer pipeline is set up. There's also a way to run gstreamer pipelines from the command line, Loial has some examples of doing this.
-
Thanks for the heads up. Sounds like it's smarter for me to wait and focus on the other parts of the code I need.
I work for one of TI's biggest competitors, so getting code under NDA might be difficult :-)