Project Logs

Collapse

• Main Control Selection - RV1126B Model Conversion Toolkit Test

  Deng MingXi • 6 days ago • 0 comments

  Why We Chose to Evaluate the RV1126B

  When exploring how to build an AI camera, the first step is to define its application scenarios—different use cases determine completely different technical approaches. AI cameras can be widely applied in visual detection fields such as smart surveillance and precision agriculture, and this article will focus on a key technical aspect of embedded visual detection: the model conversion toolkit.

  The smart surveillance industry is currently facing a core challenge: when migrating visual models from training frameworks like PyTorch/TensorFlow to embedded devices, there are widespread issues of significant accuracy degradation (caused by quantization compression) and dramatic increases in inference latency (due to hardware-software mismatch). These technical bottlenecks directly lead to critical failures such as false alarms in facial recognition and ineffective behavior analysis, making the efficiency of the model conversion toolkit a key factor in determining whether AI cameras can achieve large-scale deployment.

  It is precisely against this industry backdrop that we decided to conduct an in-depth evaluation of the RV1126B chip. The RKNN-Toolkit toolkit equipped on this chip offers three core advantages:

  1. Seamless conversion between mainstream frameworks
  2. Mixed-precision quantization that preserves accuracy
  3. NPU acceleration to enhance performance

  These features make it a potential solution to the challenges of deploying AI cameras, warranting systematic validation through our resource investment.

  Model Conversion Toolkit Evaluation

  About "How to make an AI camera", one must first clarify its intended use—different applications require fundamentally different technical approaches. AI cameras can be utilized across numerous vision-based detection domains such as smart surveillance and precision agriculture, and this article will focus on a crucial technical element in embedded vision detection: the model conversion toolkit.

  In the smart surveillance sector, the effectiveness of the model conversion toolkit has become a core technical threshold determining whether AI cameras can truly achieve scalable deployment—when transferring visual models from frameworks like PyTorch/TensorFlow to embedded devices, issues frequently arise such as drastic accuracy drops (from quantization compression) and surging inference latency (due to insufficient hardware operator adaptation), leading to critical failures like false positives in facial recognition and dysfunctional behavior analysis. These problems stem both from precision loss challenges caused by quantization compression and efficiency bottlenecks from inadequate hardware operator support.

  The RV1126B chip, with its mature RKNN-Toolkit ecosystem, provides three key advantages: seamless conversion between mainstream frameworks, mixed-precision quantization that maintains accuracy, and NPU acceleration for enhanced performance. These make it a pivotal solution for addressing AI camera deployment challenges. This article will conduct rigorous testing of this toolkit's real-world performance throughout the complete model conversion workflow. We will focus on evaluating two key aspects: the compatibility of the model conversion toolkit and the detection speed of converted models. From a compatibility perspective, the RV1126B's RKNN-Toolkit demonstrates clear strengths—supporting direct conversion of mainstream frameworks like PyTorch, TensorFlow, and ONNX, covering most current AI development model formats and significantly lowering technical barriers for model migration; however, our testing revealed that certain complex models with special architectures (such as networks containing custom operators) may require manual structural modifications to complete conversion, posing higher technical demands on developers. Regarding detection speed, empirical data shows that the YOLOv5s model quantized to INT8 achieves a 31.4ms inference latency on RV1126B,...

  Read more »

• Main Control Selection - LVGL UI Platform on AI Camera Feasibility Test

  Deng MingXi • 07/04/2025 at 08:32 • 0 comments

  The purpose of this test is to investigate the feasibility of developing a UI interface based on the AI Camera product platform, which will be built based on the LVGL framework, and compatibility issues will lead to problems that directly affect the user experience, such as face recognition results not being rendered normally, and object detection boxes being displayed abnormally.
  The real-time visualization of AI analysis results (such as dynamic tracking frames, confidence value display, etc.) is highly dependent on the graphics rendering performance of LVGL, and compatibility defects may lead to delayed display or even loss of key information, greatly reducing the value of AI functions.
  In summary, verifying whether the RV1126 development board is compatible with the LVGL tool library is crucial to the product function design of AI Recamera.

  Specific tutorials:
  1. Run the routine
  1.1 Grab the source code first

  git clone https://github.com/lvgl/lvgl.git
  git clone https://github.com/lvgl/lv_drivers.git
  git clone https://github.com/lvgl/lv_demos.git
  git clone https://github.com/lvgl/lv_port_linux_frame_buffer.git
  

  1.2 Switch branch(necessary)

  cd lvgl
  git checkout release/v8.1
  cd ../lv_drivers
  git checkout release/v8.1
  cd ../lv_demos
  git checkout release/v8.1
  cd ../lv_port_linux_frame_buffer
  git checkout release/v8.2
  git branch -a
  

  1.3 Create our project folder, copy the document and paste it inside(edit the address)

  cp lvgl/lv_conf_template.h pro/milkv/lv_conf.h
  cp -r lvgl pro/milkv
  cp lv_drivers/lv_drv_conf_template.h  pro/milkv/lv_drv_conf.h
  cp -r lv_drivers pro/milkv
  cp lv_demos/lv_demo_conf_template.h pro/milkv/lv_demo_conf.h
  cp -r lv_demos pro/milkv
  cp lv_port_linux_frame_buffer/main.c pro/milkv
  cp lv_port_linux_frame_buffer/Makefile pro/milkv
  

  The following figure shows the distribution of files after completion
  

  1.4 Next, make changes to the configuration file
  Lv_conf.h
  Changed to #if 1 to enable the content of the header file
  

  Modify the memory size to increase it appropriately
  

  
  Modify the refresh cycle, adjust it according to the performance of its own processor, I set it to 30ms
  

  Set the Tick timer configuration function
  

  Enable the font that can be used, otherwise the compilation will prompt that it is not defined
  
  

  Lv_drv_conf.h
  Change to #if 1 to enable the contents of the header file:
  

  Enable the on-screen display: USE_FBDEV enable, set the path to /dev/fb0, which is set according to the actual situation of the board
  

  Enable touchscreen inputs:
  

  Lv_demo_conf.h
  Changed to #if 1 to enable the content of the header file
  

  To enable the demo to be ported, the LV_USE_DEMO_WIDGETS is enabled here
  

  Main.c
  Set the correct path to the lv_demo.h header file
  

  
  Modify the screen buffer parameters according to the LCD pixel size, the screen I use is 320*210 pixels
  

  
  There is currently no mouse used, comment out the relevant code
  

  
  lv_demo_widgets() is the entry point to the ported demo
  

  Makefile

  Configure the cross-compiler
  
  Incorporated into lv_demo

  mouse didn't work, comment out

  Run the compiled code in the root directory of the project file

  Make clean
  
  make

  After compilation, the executable demo file is generated in the current directory
  

  1.5 Mount a shared folder
  Install the NFS server on the host
  
  

  sudo apt install nfs-kernel-server

  
  Open the /etc/exports file and add the following to the last line:
  
  

  /nfs_root *(rw,sync,no_root_squash,no_subtree_check)

  
  Run the following command to restart the NFS server for the configuration file to take effect:
  
  

  sudo /etc/init.d/rpcbind restart
  sudo /etc/init.d/nfs-kernel-server restart

  
  Execute on the development board
  
  

  mount -o nolock 192.168.0.6:/nfs_root /mnt

  
  192.168.0.6: IP address of the virtual machine
  /nfs_root: the shared directory set for the NFS server
  /mnt: After specifying this directory, Ubuntu files placed in the /nfs_root directory can be found in the /mnt directory of the board
  
  Unmount the mount
  
  

  umount /mnt

  
  
  1.6 Effect Display...

  Read more »

• Main Control Selection - RV1126 Emedded Development Board Performance Test

  jianwei wang • 07/01/2025 at 01:34 • 0 comments

  1. Executive Summary

  The purpose of this test is to evaluate the feasibility of the RV1126 development board as a core processing unit for the second generation of reCamera, focusing on:

  - Real-time video analysis capability (YOLOv5/SSD model performance)

  - Long-term operational stability (temperature/power consumption)

  - Development Environment Maturity (Toolchain Integrity)

  Conclusion:

  Final Recommendation: RV1126 may not be a good choice for 2nd-gen products(But RV1126B may be suitable), with the following conditions:

  1. Usage Constraints:
     • Suitable for single-stream 1080P@30fps detection (7-10FPS YOLOv5s)
     • Not recommended for multi-channel or high-precision scenarios
  2. Critical Improvements Required:
     • Enhanced thermal design 
     • Real-time detection performance
  3. Outstanding Risks:
     • Stability 
     • OpenCV-Python compatibility with quantized models 

  This report evaluates two commercially available RV1126 development boards (large: 10×5.5cm, small: 3.5×3.5cm) through:

  • Network bandwidth testing
  • Thermal and power measurements under CPU/NPU loads
  • RTSP streaming performance

  2. Test Results

  2.1 Large RV1126 Board Performance

  Network Bandwidth Results:

  Test Type	Protocol	Bandwidth (Mbps)	Transfer	Packet Loss	Jitter (ms)	Duration	Key Findings	Conclusion
  Single-thread TCP	TCP	93.1	222 MB	0%	-	20.03s	Fluctuation (84.4~104Mbps), 1 retransmission	Suboptimal TCP performance (93Mbps)
  Multi-thread TCP	TCP	97.6 (total)	233 MB	0%	-	20.01s	Thread imbalance (20.8~30.5Mbps per thread)	Multithreading provides minimal improvement
  UDP	UDP	500	596 MB	0%	0.165	10s	Achieves physical network limit	Validates gigabit-capable hardware

  Thermal/Power Characteristics:

  Scenario	Ext. Temp (°C)	Int. Temp (°C)	Power (W)	Observations
  Idle	36	40	0.6~0.75	Baseline measurement
  CPU stress test	62	70	1.2~1.4	30°C temperature rise
  YOLOv5 inference	73	81	2.5~2.8	Frame rate drops from 7.35 to 6.56 FPS after 10 mins at 80°C thermal equilibrium

  2.2 Small RV1126 Board Performance

  Scenario	Ext. Temp (°C)	Int. Temp (°C)	Power (W)	Observations
  Idle	36	45	0.6~0.7	Higher baseline temperature than large board
  CPU stress test	45	52	1.05~1.2	7°C temperature rise
  RTSP streaming	73	80	3.0~3.1	1920×1080 @ 2s latency, 15% CPU utilization
  SSD detection	72	81	3.0~3.4	Power stabilizes below 3W despite 90% CPU load

  Notes:

  • Board size: ~10cm²
  • RTSP streaming: 73-74°C, 2.65-2.7W power draw

  3. Test Methodology

  3.1 CPU Load Testing

  export TERM=linux
  
  stress --cpu 4 --timeout 60 &
  
  top

  3.2 Network Performance

  Connectivity Test:

  ping 192.168.253.2 -c 10

  Bandwidth Measurement:

  # Server side:
  
  iperf3 -s -B 192.168.253.1
  
   
  
  # Client side:
  
  iperf3 -c 192.168.253.1 -t 20 -P 4

  3.3 Thermal Monitoring

  while true; do
  
      echo -n "$(date '+%H:%M:%S') ";          
  
      cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq | awk '{printf "%.1f MHz ", $1/1000}';
  
      cat /sys/class/thermal/thermal_zone0/temp | awk '{printf "%.1f°C", $1/1000}';
  
      echo "";  
  
      sleep 1;  
  
  done

  3.4 Power Consumption Testing

  Testing Methodology :

  1.  Power the BV1126 development board using an adjustable power supply

  2.  Simultaneously monitor input power

  3.  Execute full-load test:

  stress --cpu 4 --timeout 180 &  # 4-core full load for 180 seconds

  Important Notes :

  1.  Temperature sensor paths may vary across devices (common paths include thermal_zone0 through thermal_zone3)

  2.  Power testing requires real-time power monitoring capability

  3.  Recommend using heat sinks during full-load tests to...

  Read more »

• PoC on SPI Display Integration

  jianwei wang • 06/12/2025 at 03:06 • 0 comments

  We've been receiving numerous feedback and suggestions from users regarding the first-generation reCamera. Indeed, during our use of the first generation, we occasionally encountered areas where the user experience wasn't yet sufficiently friendly.

  Therefore, before finalizing the form factor of the second generation, we will continue to conduct ongoing testing and development and update our test logs here on a regular basis.

  We often encounter difficulties when using the reCamera 2002w:

  1. Obtaining the IP address during initial setup – For example, immediately after connecting the Ethernet cable to the reCamera.
  2. Verifying real-time configuration – Such as confirming whether the current resolution, frame rate (FPS), and video recording status are functioning as intended.
  3. Monitoring the camera’s field of view – When mounted in inaccessible locations (e.g., a ceiling corner), it is impossible to simultaneously view the live feed via a web interface.

  To address these issues, we have decided to integrate a small SPI display (not the Raspberry Pi screen) into our next-generation reCamera hardware.

  We tested two different size display (1.69 and 1.47 inch), and designed a simple UI on it.

• First-gen, reCamera 2002 (w)

  jenna • 04/28/2025 at 06:49 • 0 comments

  First-gen reCamera

  Core Board V1

  So far, we have launched reCamera Core powered by RISC-V SOC SG2002. In addition to the onboard eMMC, there is also an onboard wireless solution ready for use. The wireless module, along with the onboard antenna, could provide you with basic Wi-Fi/BLE connection ability.

  The difference between C1_2002W and C1_2002 is whether there is an onboard WIFI chip. They are from the same PCB design. The difference is that C1_2002 does not attach the Wi-Fi module.

  Below are the introductions to these two core boards.

  Board	Features	Version
  C1_2002w	- eMMC - WiFi/BLE module - Onboard antenna - External antenna connector	1.2
  C1_2002	- eMMC - Extra SDIO to base board - Extra UART to base board	1.2

  The schematic is as below:
  

  
  

  Sensor Board V1

  The sensor board we have currently developed is the OV5647.

  Sensor	OV5647	CMOS Size	1/4"
  Pixels	5MP	Aperture	F2.8
  Focal Length	3.46mm	Field of View	65°
  Distortion	< 1%	Image	2592 x 1944 (still picture)
  Video	1920 x 1080p @30fps, 1280 x 720p @60fps, 640 x 480p @60fps, 640 x 480p @90fps
  Interfaces	- 4 x LED fill lights - 1 x microphone - 1 x speaker - 3 x LED indicator

  Top View	Bottom View

  Base Board V1

  So far, we have developed two types of baseboards, B101_Default and B401_CAN. B401_CAN supports CAN communication and allows for the connection of more accessories, for example, you can connect a gimbal to achieve 360° yaw rotation full coverage and 180° pitch range from floor to ceiling.

  B101_Default

  Top View	Bottom View

  B401_CAN

  Up	Bottom

View all 5 project logs