Jump to content

atomic77

Members
  • Posts

    14
  • Joined

  • Last visited

Posts posted by atomic77

  1. Thank you for sharing this! I have a DHT22 that i've been trying to get working with an OrangePi Lite and I've had terrible results with all of the python-based libraries i've tried. I'm getting about 25-30% of the readings with this every 2s, which is good enough for my purposes.

     

    FWIW, my opi lite is showing about 5.2 and 3.8v for the 5V and 3.3V pins

  2. I tried a build of 5.14 and made a couple of adjustments in u-boot-rockchip64-edge/add-board-orangepi-r1plus to include the rk3328-nanopi-r2s.dtb file instead of the rk3328-nanopi-r2-rev00.dtb, but the board doesn't come up and has the same issue reported originally:

     

    Spoiler

    U-Boot 2020.10-armbian (Sep 12 2021 - 16:36:11 +0000)

     

    Model: Xunlong Orange Pi R1 Plus
    DRAM:  1022 MiB
    PMIC:  RK8050 (on=0x40, off=0x00)
    MMC:   mmc@ff500000: 1
    Loading Environment from MMC... MMC Device 0 not found
    *** Warning - No MMC card found, using default environment

    In:    serial@ff130000
    Out:   serial@ff130000
    Err:   serial@ff130000
    Model: Xunlong Orange Pi R1 Plus
    Net:   eth0: ethernet@ff540000
    Hit any key to stop autoboot:  0
    switch to partitions #0, OK
    mmc1 is current device
    Scanning mmc 1:1...
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 5 ms (622.1 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 1
    177 bytes read in 4 ms (43 KiB/s)
    11093764 bytes read in 485 ms (21.8 MiB/s)
    29071872 bytes read in 1264 ms (21.9 MiB/s)
    52137 bytes read in 9 ms (5.5 MiB/s)
    2698 bytes read in 8 ms (329.1 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    ## Executing script at 09000000
    Moving Image from 0x2080000 to 0x2200000, end=3e50000
    ## Loading init Ramdisk from Legacy Image at 06000000 ...
       Image Name:   uInitrd
       Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
       Data Size:    11093700 Bytes = 10.6 MiB
       Load Address: 00000000
       Entry Point:  00000000
       Verifying Checksum ... OK
    ## Flattened Device Tree blob at 01f00000
       Booting using the fdt blob at 0x1f00000
       Loading Ramdisk to 3d499000, end 3df2d6c4 ... OK
       Loading Device Tree to 000000003d423000, end 000000003d498fff ... OK

    Starting kernel ...

    Loading, please wait...
    Starting version 241
    Begin: Loading essential drivers ... done.
    Begin: Running /scripts/init-premount ... done.
    Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
    Begin: Running /scripts/local-premount ... done.
    Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    Begin: Running /scripts/local-block ... done.
    done.
    Gave up waiting for root file system device.  Common problems:
     - Boot args (cat /proc/cmdline)

     

    What I don't quite get is why nanopi r2s is the basis for the r1 plus image, though the device tree seems to be quite different from the rock pi e, which seems to work pretty well without any adjustments at all?

     

     

  3. I finally had some time this weekend to dig into this. It's my first exposure to the armbian kernel build process and device tree files, so please forgive any stupid questions! I made a first attempt at the changes on my github fork.

     

    I was not able to get the kernel built if I completely removed the nanopi-r2s patch as there was some extra dependencies on rockchip-ddr.h. So I started by removing the rev00/rev20 DTS files that seemed to conflict with the mainline, and tried to find any references to the old files and change them.

     

    What isn't clear to me is should I be also rewriting the u-boot patch files based on the upstream kernel version as well ? Are those copied completely from the source tree?

     

    When I try to boot, I get an error - is there a way I can get more details on what has gone wrong?

     

    Spoiler
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 6 ms (517.6 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 1
    132 bytes read in 4 ms (32.2 KiB/s)
    12006837 bytes read in 526 ms (21.8 MiB/s)
    28779008 bytes read in 1252 ms (21.9 MiB/s)
    Failed to load '/boot/dtb/rockchip/rk3328-orangepi-r1-plus.dtb'
    libfdt fdt_check_header(): FDT_ERR_BADMAGIC
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!

     

     

    I hope I'm not too far off course with my changes, any help is appreciated!

  4. I recently got my hands on an R1+ and was able to get it booted with a RockPi-E buster image, though I get the same error when I try to use any of the orangepi-r1plus images.

     

    Since I have the hardware, I'd be open to making the needed changes to get this particular board to work in a PR to the armbian/build repo. Can anyone give me any pointers to what might need to change in the orangepi-r1plus image to get there?

  5. Confirmed that I can't reproduce this on Stretch 5.4.45.

     

    I'm leaning towards just disabling zram on 5.8 kernels - as far as I can tell, the main thing I need to watch out for is that I don't fill up 50MB of logs within the 15 minute interval of armbian-truncate-logs being run (now that it's not compressed)?

  6. Hi all,

     

    I've been doing some stress tests to trigger the watchdog on an Orange Pi Zero and I discovered that i can reliably reproduce a kernel oops with a simple fork bomb on a fresh install of the latest Armbian Buster image (Armbian_20.11_Orangepizero_buster_current_5.8.16.img.xz)

    Spoiler


    
    [  118.737219] Internal error: Oops: 5 [#1] SMP THUMB2
    [  118.742106] Modules linked in: xradio_wlan mac80211 btusb btintel btrtl sun4i_gpadc_iio btbcm industrialio bluetooth sun8i_thermal cfg80211 ecdh_generic rfkill ecc libarc4 sun8i_ce crypto_engine sunxi_cedrus(C) sun8i_di zram uio_pdrv_genirq uio cpufreq_dt usb_f_acm u_serial g_serial libcomposite ip_tables x_tables autofs4 pwrseq_simple sunxi phy_generic
    [  118.773408] CPU: 3 PID: 3792 Comm: bash Tainted: G         C        5.8.16-sunxi #20.08.14
    [  118.781661] Hardware name: Allwinner sun8i Family
    [  118.786372] PC is at obj_malloc+0x28/0xf0
    [  118.790378] LR is at zs_malloc+0x149/0x364
    [  118.794469] pc : [<c0262500>]    lr : [<c0262c4d>]    psr: 20010133
    [  118.800725] sp : c890b880  ip : cdf4a208  fp : cdf4a201
    [  118.805942] r10: 1bc20381  r9 : 4a5ff920  r8 : d4bac480
    [  118.811159] r7 : cc318fc0  r6 : 0004a5ff  r5 : 00000000  r4 : 00000000
    [  118.817677] r3 : 00000004  r2 : 00000000  r1 : cc318fc0  r0 : d4bac480
    [  118.824197] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment none
    [  118.831495] Control: 50c5387d  Table: 4b1e406a  DAC: 00000051
    [  118.837234] Process bash (pid: 3792, stack limit = 0x064576e6)
    [  118.843058] Stack: (0xc890b880 to 0xc890c000)
    [  118.847414] b880: 00000001 d4bac480 cdf4a200 c9d1b800 0000280a 00002800 cdf4a200 cc318fc0
    [  118.855584] b8a0: bf85f440 c0262c4d d6adc000 00000001 d7bf6d30 c890b8f8 00002000 c04efee1
    [  118.863752] b8c0: d6adc000 c0f04fc8 000008d9 d48f0c00 00000000 c890a000 d7928dd0 00000000
    [  118.871921] b8e0: ff7f6760 c100247c bf85f440 bf85ccd3 00000ed7 00000001 000008d9 c0f04fc8
    [  118.880089] b900: ffff4ef6 000076b8 00000000 d48f0c00 d65edf80 00000001 d7928dd0 00000000
    [  118.888257] b920: ffff4ef6 bf85d22d 00000000 c029f57b d7928dd0 00001000 00000000 c0f04fc8
    [  118.896425] b940: ffffffff 00000000 d65edf80 000076b8 00000000 d7928dd0 bf85e064 00000001
    [  118.904593] b960: c890bad8 c029f5a9 d7928dd0 00000001 38e38e39 d7928dd0 d65edf80 c890ba48
    [  118.912762] b980: c024745d d5689e00 c890bae0 c02477c7 d7928dd0 c890ba48 00000000 c024d489
    [  118.920930] b9a0: c10323a8 c27be0c0 00001000 d7928dd0 00000ed7 c0f04fc8 cc5c89d8 d7928dd0
    [  118.929099] b9c0: c0f28fe4 d7928dd0 00000000 c0f055f4 d52503c0 00000ed7 c890bad8 c024d489
    [  118.937267] b9e0: d7928dd0 c890ba48 00000000 c0f04fc8 d5689e00 d7928dd4 d7928dd0 00000000
    [  118.945435] ba00: c890bc64 d5689e00 c890bae0 c02172b7 00000001 00000000 ffffe000 00000000
    [  118.953603] ba20: 00000003 00000000 c0fd71c0 c0e961cc 00000380 00000001 c890ba38 c890ba38
    [  118.961771] ba40: d792cc20 d791ca80 00000020 00000000 00000000 00000000 ffffffff 7fffffff
    [  118.969938] ba60: 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000
    [  118.978106] ba80: 00000000 00000000 00000000 c0f04fc8 c0f04fc8 c890bc64 c0e96180 d6267000
    [  118.986275] baa0: c0fd71c0 00000020 00000000 00000007 c0fd7cc0 c0218217 c890bae0 00000000
    [  118.994443] bac0: c890bc64 00000003 fffffffe 00000068 00000000 00000020 d7bdc808 d792a25c
    [  119.002610] bae0: 00000000 00000000 00000000 00000000 00000000 00000003 00000000 00000000
    [  119.010778] bb00: 00000000 00000000 00000000 c0f04fc8 c021878f c890bc64 d6267000 00000020
    [  119.018946] bb20: 00000000 00000000 51eb851f 00000000 c890bb70 c0218983 0001b06e ffffffff
    [  119.027115] bb40: 000001ee 00000000 e0802000 00000020 000001ed 00000000 c890bb58 c890bb58
    [  119.035283] bb60: c890bb60 c890bb60 80000000 00000031 00000045 00000001 00000001 c0193615
    [  119.043451] bb80: 00000051 00000045 00000001 00000001 c0193615 c0f04fc8 00000000 c890bc64
    [  119.051619] bba0: cd6ef800 00000000 c0f05604 00000000 0000000e 00000028 c0fd71c0 c0218c7d
    [  119.059787] bbc0: 00000000 c0fd71c0 d7006e00 00000000 0000001f 00000000 c0f04ac0 c0f15808
    [  119.067956] bbe0: c0fd7cc0 c890bc8c c890bca8 c0f04a80 00400dc2 c890bc64 c0fd7c40 c0fd71c0
    [  119.076124] bc00: 00000000 00400dc2 c0fd7c40 00000000 c1035d74 c02190ff 00100cc0 00200010
    [  119.084292] bc20: c890a000 0000000c c890bc18 c0e96180 00000000 c0f04fc8 00000840 00000001
    [  119.092460] bc40: 00400dc2 00000000 00000000 c0fd7c40 c890a000 00400dc2 00000000 c0219d11
    [  119.100628] bc60: 00000001 00000020 00000000 00000000 000021bc 00000170 0600007a 00000001
    [  119.108796] bc80: 00400dc2 00000012 00000028 00000001 00000001 00000000 00000000 00000000
    [  119.116964] bca0: 0000000b 0000000e 00000000 c0f04fc8 00400140 cd67af40 00400940 00000000
    [  119.125133] bcc0: c0f054d0 c0243729 dff969c0 dff95ae4 dff96f78 00000001 c0792aa1 00000840
    [  119.133301] bce0: 00000000 00000000 00400dc2 00000000 dff969c0 cc55e5c0 16953a8c 00000840
    [  119.141469] bd00: 16421569 00000001 00000000 00000400 00000000 00000000 005009c2 00000000
    [  119.149637] bd20: c0f054d0 00000000 00000000 00000840 00000810 00400dc2 00000010 00000850
    [  119.157805] bd40: 00000049 c0146567 c0fd7c40 00000000 c0fd7c40 00000000 00000001 00000000
    [  119.165973] bd60: cc55e5c0 c013d8ef c0a025c0 c0a02624 dff96980 c890bd80 20000113 c013d8ef
    [  119.174142] bd80: c890bdd4 c0f04fc8 cc55e540 c8d9e200 c8d9e200 cc728010 004f7000 d5accaa8
    [  119.182310] bda0: 004f7000 c890a000 c8a3bde0 c0230273 cc728010 c8d9e200 cc728010 00000000
    [  119.190479] bdc0: 004f7000 c0230d7d c890bde0 cb1e4018 cc728010 004f9000 00000000 c0f04fc8
    [  119.198647] bde0: c8b3be04 cc55e9e0 004f9000 c81ae360 c890be08 00000000 c8a3bdf0 d5accac8
    [  119.206815] be00: d6330200 004f8fff d5accac8 00000000 00000000 00000000 00000000 c0f04fc8
    [  119.214983] be20: c8a3ba20 c8a3ba20 c8d9e200 d6330200 c81ae360 d5accaa8 c8a3ba30 d5accac8
    [  119.223152] be40: c8a3bde0 c011949b c15d4340 c0254a7f c8a3ba28 c8a3ba34 c890a000 d6330240
    [  119.231320] be60: c8d9e240 c100257c c1706500 c890be6c c890be6c c0f04fc8 c1f1fa5c 01200000
    [  119.239488] be80: cc55ca40 00000000 ffffe000 c890a000 c6514c00 00000000 00000000 c011a759
    [  119.247656] bea0: d6330240 00000800 00000255 c890bf58 00000000 00000000 00000000 00000000
    [  119.255825] bec0: 00000000 00000000 c100257c cc55cd54 00000000 ffffe000 fffffff4 00000000
    [  119.263993] bee0: 00000000 00000000 c175bc34 c0f04fc8 00000cc0 b6ff5238 00000000 c890bf58
    [  119.272161] bf00: 00000078 c0100284 c890a000 00000078 01200000 c011ab5f cd67b37c c0126d4b
    [  119.280329] bf20: c890bfb0 01e176e4 0000080f c0f04fc8 d6330200 b6ff5238 00101000 00000000
    [  119.288498] bf40: 00000078 c0100284 c890a000 00000078 01e2b7c8 c011b07f 01200000 00000000
    [  119.296665] bf60: 00000000 b6ff5238 00000000 00000011 00000000 00000000 00000000 00000000
    [  119.304833] bf80: 00000000 00000000 00000000 00000000 b6ff6968 c0f04fc8 00000000 b6ff5238
    [  119.313001] bfa0: b6ff5690 c0100061 b6ff5238 b6ff5690 01200011 00000000 00000000 00000000
    [  119.321169] bfc0: b6ff5238 b6ff5690 00000000 00000078 be95ab6c 00000000 b6ff51d0 01e2b7c8
    [  119.329337] bfe0: 00000078 be95aab0 b6f09253 b6eab746 20000030 01200011 00000000 00000000
    [  119.337518] [<c0262500>] (obj_malloc) from [<c0262c4d>] (zs_malloc+0x149/0x364)
    [  119.344838] [<c0262c4d>] (zs_malloc) from [<bf85ccd3>] (zram_bvec_rw.constprop.0+0x35b/0x52c [zram])
    [  119.353979] [<bf85ccd3>] (zram_bvec_rw.constprop.0 [zram]) from [<bf85d22d>] (zram_rw_page+0xa1/0x120 [zram])
    [  119.363890] [<bf85d22d>] (zram_rw_page [zram]) from [<c029f5a9>] (bdev_write_page+0x71/0x9c)
    [  119.372329] [<c029f5a9>] (bdev_write_page) from [<c02477c7>] (__swap_writepage+0x47/0x280)
    [  119.380591] [<c02477c7>] (__swap_writepage) from [<c02172b7>] (shrink_page_list+0x6e3/0xa74)
    [  119.389022] [<c02172b7>] (shrink_page_list) from [<c0218217>] (shrink_inactive_list+0x15b/0x300)
    [  119.397798] [<c0218217>] (shrink_inactive_list) from [<c0218983>] (shrink_lruvec+0x27b/0x444)
    [  119.406313] [<c0218983>] (shrink_lruvec) from [<c0218c7d>] (shrink_node+0x131/0x4f0)
    [  119.414049] [<c0218c7d>] (shrink_node) from [<c02190ff>] (do_try_to_free_pages+0xc3/0x2e0)
    [  119.422305] [<c02190ff>] (do_try_to_free_pages) from [<c0219d11>] (try_to_free_pages+0xcd/0x1b4)
    [  119.431083] [<c0219d11>] (try_to_free_pages) from [<c0243729>] (__alloc_pages_nodemask+0x3d9/0xc40)
    [  119.440122] [<c0243729>] (__alloc_pages_nodemask) from [<c0230273>] (__pte_alloc+0x1f/0x118)
    [  119.448552] [<c0230273>] (__pte_alloc) from [<c0230d7d>] (copy_page_range+0x455/0x554)
    [  119.456467] [<c0230d7d>] (copy_page_range) from [<c011949b>] (dup_mm+0x21f/0x340)
    [  119.463947] [<c011949b>] (dup_mm) from [<c011a759>] (copy_process+0xf75/0x1218)
    [  119.471250] [<c011a759>] (copy_process) from [<c011ab5f>] (_do_fork+0x63/0x344)
    [  119.478555] [<c011ab5f>] (_do_fork) from [<c011b07f>] (sys_clone+0x5b/0x74)
    [  119.485514] [<c011b07f>] (sys_clone) from [<c0100061>] (ret_fast_syscall+0x1/0x62)
    [  119.493071] Exception stack(0xc890bfa8 to 0xc890bff0)
    [  119.498110] bfa0:                   b6ff5238 b6ff5690 01200011 00000000 00000000 00000000
    [  119.506279] bfc0: b6ff5238 b6ff5690 00000000 00000078 be95ab6c 00000000 b6ff51d0 01e2b7c8
    [  119.514444] bfe0: 00000078 be95aab0 b6f09253 b6eab746
    [  119.519494] Code: 3629 2e00 dd08 2300 (6825) 3301
    [  119.525481] ---[ end trace 0bcf63ee4f72ab80 ]---
    


     

    The command run as root is:

    :(){ :|: & };:

     

    I noticed zs_malloc in the stack trace, and interestingly enough, it does not happen if I disable zram in /etc/default/armbian-zram-config. I get a flood of errors like below, and the device eventually recovers.

     

    -bash: fork: Resource temporarily unavailable
    -bash: fork: retry: Resource temporarily unavailable
    -bash: fork: retry: Resource temporarily unavailable
    -bash: fork: retry: Resource temporarily unavailable
    -bash: fork: Resource temporarily unavailable
    

     

    I know the obvious answer is "don't do that" :D My memory requirements for this pi zero are modest, but stability is much more important. Can anyone suggest a good reason to not disable zram after seeing this? I also wonder where the right place to report this issue would be.

     

    Thanks,

    Alex

  7. I got my hands on a "Set 9" Orange Pi Lite + GC2035 camera a while back and I've finally been able to put together a self-contained object detection device using Tensorflow, without sending any image data outside for processing.


    Basically, its a python Flask application that captures frames from the camera using a GStreamer pipeline. It runs them through a Tensorflow object detection model and spits out the same frame with extra metadata about objects it found, and renders a box around them. Using all four cores of the H2 it can do about 2-3 fps. The app keeps track of the count of all object types it has seen and exposes the metrics in prometheus format, for easy creation of graphs of what it sees over time with Grafana :)

     

    grafana-dashboard.png


    I'll explain some of the more interesting aspects of how I got this to work here in case anyone else wants to try to get some use out of this very inexpensive hardware, and I am grateful to the many posts on this forum that helped me along the way!


    Use a 3.4 kernel with custom GC2035 driver


    Don't bother with anything new - the GC2035 was hopeless on any newer builds of Armbian I tried. The driver available at https://github.com/avafinger/gc2035.git provided far better image quality. After installing the updated GC2035, I run the following to get the camera up and running:

     

    sudo sunxi-pio -m "PG11<1><0><1><1>"
    sudo modprobe gc2035 hres=1
    sudo modprobe vfe_v4l2

     

    Install Tensorflow lite runtime

     

    Google provides a tensorflow runtime as a binary wheel built for python 3.5 armv7. When pip installing, expect it to take 20 minutes or so as it will need to compile numpy (the apt repo version isn't recent enough)

     

    wget https://github.com/google-coral/pycoral/releases/download/release-frogfish/tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl
    sudo -H pip3 install tflite_runtime-2.5.0-cp35-cp35m-linux_armv7l.whl

     


    Build opencv for python 3.5 bindings


    This was something I tried everything I could to avoid, but I just could not get the colour conversion from the YUV format of the GC2035 to an RGB image using anything else I found online, so I was dependent on a single color-conversion utility function.

     

    To build the 3.4.12 version for use with python (grab lunch - takes about 1.5 hours :-O )


     

    cmake -DCMAKE_INSTALL_PREFIX=/home/atomic/local -DSOFTFP=ON \
        -DBUILD_TESTS=OFF -D BUILD_PERF_TESTS=OFF -D BUILD_opencv_python2=0 \
        -D BUILD_opencv_python3=1 -D WITH_GSTREAMER=ON \
        -D PYTHON3_INCLUDE_PATH=/usr/include/python3.5  ..
    make -j 4
    make install
    
    # Check that ~/local/lib/python3.5/dist-packages should now have the cv2 shlib
    export PYTHONPATH=/home/atomic/local/lib/python3.5/dist-packages

     

     

    Build gstreamer plugin for Cedar H264 encoder

     

    This is required to get a working gstreamer pipeline for the video feed:

    git clone https://github.com/gtalusan/gst-plugin-cedar
    ./autogen.sh
    sudo make install
    # When trying against a pipc I had to copy into .local to get gstreamer to recognise it
    cp /usr/local/lib/gstreamer-1.0/libgst* ~/.local/share/gstreamer-1.0/plugins/
    # Confirm that plugin is installed:
    gst-inspect-1.0 cedar_h264enc
    

     

    Processing images

     

    The full app source is on github, but the more interesting parts that took me some time to figure out were about getting python to cooperate with gstreamer:

     

    Frames from the camera arrive to python at the end of the pipeline as an appsink. The Gstreamer pipeline I configured via python was:

     

        src =  Gst.ElementFactory.make("v4l2src")
        src.set_property("device", "/dev/video0")
        src.set_property("do-timestamp", 1)
        filt = Gst.ElementFactory.make("capsfilter")
        filt.set_property("caps", Gst.caps_from_string("video/x-raw,format=NV12,width=800,height=600,framerate=12/1"))
        p1 = Gst.ElementFactory.make("cedar_h264enc")
        p2 = Gst.ElementFactory.make("h264parse")
        p3 = Gst.ElementFactory.make("rtph264pay")
        p3.set_property("config-interval", 1)
        p3.set_property("pt", 96)
        p4 = Gst.ElementFactory.make("rtph264depay")
        p5 = Gst.ElementFactory.make("avdec_h264")
        sink = Gst.ElementFactory.make("appsink", "sink")
        pipeline_elements = [src, filt, p1, p2, p3, p4, p5, sink]
    
        sink.set_property("max-buffers", 10)
        sink.set_property('emit-signals', True)
        sink.set_property('sync', False)
        sink.connect("new-sample", on_buffer, sink)


    This pipeline definition causes a callback on_buffer to be called every time a frame is emitted from the camera:


     

    def on_buffer(sink: GstApp.AppSink, data: typing.Any) -> Gst.FlowReturn:
        # Sample will be a 800x900 byte array in a very frustrating YUV420 format
        sample = sink.emit("pull-sample")  # Gst.Sample
        ... conversion to numpy array
        # rgb is now in a format that Pillow can easily work with
        # These two calls are what you compiled opencv for 1.5 hours for :-D
        rgb = cv2.cvtColor(img_arr, cv2.COLOR_YUV2BGR_I420)
        rgb = cv2.cvtColor(rgb, cv2.COLOR_BGR2RGB)


    Once you have a nice pillow RGB image, it's easy to pass this into a Tensorflow model, and there is tons of material on the web for how you can do things like that. For fast but not so accurate detection, I used the ssdlite_mobilenet_v2_coco pretrained model, which can handle about 0.5 frames per second per core of the H2 Allwinner CPU.

     

    There are some problems I still have to work out. Occasionally the video stream stalls and I haven't figured out how to recover from this without restarting the app completely. The way frame data is passed around tensorflow worker processes is probably not ideal and needs to be cleaned up, but it does allow me to get much better throughput using all four cores.

     

    For more details, including a detailed build script, the full source is here:

    https://github.com/atomic77/opilite-object-detect

  8. I was trying to do the same thing with my pihole running debian. Disabling the wpa_supplicant service didn't work for me because it seemed to get dragged up by polkit. Did you solve the problem?

     

    The only way I could figure out to prevent wpa_supplicant from coming up was to disable network-manager entirely. Since I set my ip statically with interfaces file it's ok for me but I imagine there is a better way.

  9. Hello all,

     

    I recently went through the exercise of getting the Armbian build system set up to create an image with some of my user customizations, similar to the example with OMV. The documentation and forums have been a huge help!

     

    As I am running Fedora and Windows as my main OSes, I did struggle a bit at first. I tried, in order:

     

    • Ignoring the advice of the documentation, and running ./compile.sh on Fedora. Didn't get far :)
    • Running the build with Docker on Fedora. I ran into a number of different problems and ultimately gave up.
    • Running on Ubuntu 18.04 on WSL2. I did eventually get a build to complete, but the image may have been corrupt because my device didn't boot at all
    • Considered using Vagrant, but decided to give Multipass a try. Worked like a charm on the first try on both my environments!

     

    I didn't find anything on the forums or documentation about using multipass to manage build VMs, so I decided to create a small gist here documenting how I got it working: https://gist.github.com/atomic77/7633fcdbf99dca80f31fd6d64bfd0565

     

    For any not familiar, multipass is a Canonical tool that is optimized for creating Ubuntu VMs, which seems perfect for Armbian since that's the preferred platform anyway. Since it's so focused, it's very simple to use and all the utilities like shared mounts work seamlessly compared to Vagrant.

     

    If this could be helpful to others, I'd be happy to incorporate any feedback into a page for the documentation.

  10. Hello all,

     

    I've been recently burned by a failing SD card (armbianmonitor -v possibly saved me a much worse fate!) and I'm now trying to proactively avoid a similar situation.

     

    I found that WD has a line of cards that claim a health status feature that  "Helps in preventive maintenance by signaling when the card needs to be replaced". One of them is the Purple QD101 that seems reasonably priced at $15 for 64GB.

     

    I'm not finding much in the way of details of how this is exposed though. Is there any way to get access to this information on linux?

  11. I know this thread is over a year old, but I was finally able to get decent camera output out of the GC2035 thanks to the cedar H264 gstreamer plugin linked here!

     

    I'm no gstreamer expert, but what i've been able to figure out is that after the cedar_h264enc stage of the pipeline, you need to add a h264parse stage, which you can then follow with something like matroskamux if you want to write a .mkv file, or rtph264pay if you want to send the data over the network via RTP. eg:

     

    gst-launch-1.0 -ve v4l2src device=/dev/video0 \
    ! video/x-raw,format=NV12,width=800,height=600,framerate=15/1  \
    ! cedar_h264enc ! h264parse ! queue \
    !  matroskamux ! filesink location=test.mkv

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines