Wont work on Jetson Nano following install instructions #60
Comments
|
@vic4hub it probably doesn't work because we don't have support for ARMv8, which appears to be the processor on the Jetson Nano if I'm reading correctly. Can you confirm? @jgottula did some work earlier to support adding ARMv8 from someone else who asked for it, but that person disappeared once it was ready to go so we had no one to test it. If you're willing to actually test it @jgottula might be willing to help with reviving that work. What are you hoping to use this software to do? |
|
I had a hangup previously when trying to package the ARM variants of the libs, due to there not being a clear mapping between the ARMv5, ARMv6, ARMv7, ARMv8 binaries from ZWO and the actual ARM architecture names in Debian. Fortunately I think I have cracked that problem, and it looks like Debian arch to ZWO lib mapping should essentially be this:
So maybe now I can get those appropriately packaged so that the listed arch is correct and "just works". (Reference: https://wiki.debian.org/ArmHardFloatPort#Name_of_the_port) As for Oh and also 1.17 exists now. I should probably add that on top of the other things as well. |
|
Ah but wait, I need to figure out what arbitrary triplet they decided to use for each ARM port of Debian as well, sigh... |
Seems to be:
(Reference: https://wiki.debian.org/Multiarch/Tuples) I've pushed new bin packages to the apt repo just now, which, at least in theory, should "just work" when pulled in as dependencies by the |
I've now backported ARMv7 and ARMv8 support for SDK v1.16.3 onto that branch. |
This still remains to be done. |
|
you guys are awesome! let me know what would be needed from me, I can certainly test stuff. It would be amazing to get zwo to run in v4l2 (I know that's outside of scope of this repo) |
|
Yeah so next steps to test stuff:
|
|
puked: ~/zwo/capture$ make |
|
The README doesn't make it obvious enough but you need to install the dependencies for |
|
ah yes, thought I had all that as I recently compile opencv4.5 and pycuda stuff, anyhow g++: error: unrecognized command line option ‘-m64’ |
|
Try commenting out the line |
|
Yep that did the trick and it works, I actually get the damn camera feed! Anyhow here is part of the log, seems something is still not quite there (or is it? let me know what else you'd like to see): sudo ./capture preview thread id: 17596 |
|
Okay well that's progress! It appears as though are emitted every time Some things you can try:
Let us know what you find. |
|
Oh another thing you can try: Run |
This Makefile is frankly an abomination. It's still originally based on the crusty ugly Makefile provided with the demo programs in the ASK SDK. The necessity to manually adjustment of the PLATFORM variable in the Makefile is idiotic and really should not need to be there, except maybe in cases of cross-compilation.
It's exactly as stupid and awful as you'd expect, sadly. |
|
I highly suspect you'll find that you're topping out on CPU. In part because USB is somewhat inherently CPU-intensive, and also because of the number of times big buffers get copied around in memory for no especially justifiable reason. I bet we're able to get away with a fair bit more bandwidth before topping out on our Core i3-7320 system than on that NVIDIA Cortex-A57 SoC. (Also I have no idea how good of a job NVIDIA did at making sure the I/O to their XHCI controller is beefy enough; might be totally fine, might turn out that it can't actually sustain 5Gbps in reality, who knows.) |
|
Awesome-sauce! Thank you guys so much, I'm in EST, shall play around with this tonight and report back. My intentions are definitely to not just take, but to give back and help. |
This Makefile is frankly an abomination. It's still originally based on the crusty ugly Makefile provided with the demo programs in the ASK SDK. The necessity to manually adjustment of the PLATFORM variable in the Makefile is idiotic and really should not need to be there, except maybe in cases of cross-compilation.
|
I guarantee that last fix only touched x64; but I guess re-test anyway. There may have been other force-pushes I did prior to that one which potentially affected something else. |
|
hey guys, just did, had to clean and comment out -m64 out once again and rebuild. What should I be looking out for when running? |
|
I get the following: preview thread id: 9966 |
|
Okay, looks like nothing significant changed, which is expected. You should be able to just un-comment the Next would probably be useful to look at |
|
Also here is what the tree looks like, I should also fully disclose that I'm using chromium in here with a few tabs open |
|
Okay, interesting. So the Yeah I guess next to try would be the other things I mentioned here: #60 (comment) |
|
all good. just tried binning down to 4 no difference. gonna fool around with the "magic knob" and report back. |
|
yep magic knob works and the magic number for nvidia jetson nano is 40 anything above drops frames. Also notable, cpu's are pegged and fps gets an impressive 12fps lol (per sony imx178 tops at 60fps)
|
|
what are you guys getting on your rigs in terms of fps, also what are your rigs? I think it is likely that one can get better results going headless w/ realtime priority. |
|
Very interesting, thanks for reporting your findings. I should point out that the frame rate shown in the title bar of the preview window is an estimate of the rate of frames actually shown in that window, which is often lower than the frame rate the software is successfully pulling from the camera. The preview window's thread displays frames as fast as it can but skips frames as needed so it isn't a bottleneck. So you might actually be getting something between 12 and 60. I suppose I ought to add a running frame rate from the camera estimate somewhere. As a crude work-around you can use a stopwatch or something and look at the frame count printed to the console over some time interval. We are using a Shuttle DH270 with an Intel Core i3-7320 processor and Samsung 960 EVO 500GB SSD. We picked the specs on that machine largely to be capable of keeping up with the firehose of data that comes out of this camera. In our case, we care most about getting all the frames written to disk. We are able to achieve very close to the advertised 60 FPS (after much pain and suffering). |
This Makefile is frankly an abomination. It's still originally based on the crusty ugly Makefile provided with the demo programs in the ASK SDK. The necessity to manually adjustment of the PLATFORM variable in the Makefile is idiotic and really should not need to be there, except maybe in cases of cross-compilation.
Hey thank you for setting this up. I am trying to get this working on Jetson Nano and get the following error when installing per readme:
sudo apt install libasicamera2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libasicamera2 : Depends: libasicamera2-bin (= 1.16.3-4) but it is not installable
E: Unable to correct problems, you have held broken packages.
The text was updated successfully, but these errors were encountered: