The project is not quite done yet. I started to clean-code but changed to kind of hacking things together after some parts took much longer then expected, especially the HW part and DPU system.
A detailed overview on what actually works and what currently does not work (and why) is given in the section ‘Future work’ and ‘Lessons learned’ below.
A selection of source code is attached but not every single script and Makefile where I did some changes on (apply a .zip was not possible). Further releases will be handled in a gitlab repository.
For tips on how to improve things I am very grateful.
Before you start into the project, please read the 'Lessons learned' section!
Otherwise, have fun hacking!
1. About the IDEASimple : A expandable and inexpensive full 3DoF (three degree of freedom) robot that can follow/pick objects in motion even if they are on a fast and unknown trajectory. The Robot shall be able to learn to recognize new objects with an easy and All-In-One ML solution. The project shall enable users to have a full 3DoF system/pipeline with AMD enabled Hardware accelerators for Computer Vision/Object detection. It includes full open source code as well as a build flow to change and adapt on their very own needs. In common: A robotic third hand, that helps to reduce tedious and repeating tasks.
1.1. Use-casesSome of the many use-cases are listed below
The system could be used as entry level training robot with object detection and acceleration capabilities for a low price-point for universities.
There is also the possibility to use it for finding/cleaning objects or providing objects on a work-bench when mounted on a moving rail.
When the 3DoF system is mounted on a 3-axis system, it can be used to pick and place objects in a storage facility by passing by on containers/boxes with lean (unboxed) objects.
It could be used as a multi-array (multiple 3DoF autonomous on a train-system) pick and place system where every 3DoF picks/sorts objects on the move.
There could be a potential benefit on environments where human control is beyond possibility. F.e. on a planet rover on var away planets where the task is to autonomously collect some special sized rocks. Furthermore on environments to dangerous to operate for humans, f.e. finding objects in deep sea wracks ect.
On every environment where the 3DoF system has no impact on the moving part and must adopt to movement. F.e. the rover will not stop for the picking arm.
One of the most valuable use cases is to use the 3DoF on an existing conveyor belt. The customer simply learns the objects to track and pick and the system can, without big calibration or human help, start picking those objects. Examples include:
- Removing special trash (like plastic caps, etc.) from a recycling factory conveyor belt
- Removing defects on a food production line, f.e. apples with soft spots
- Package objects in randomly angled transport boxes and detect/replace missing pieces
- etc.
Expandable robot: HW built in a way that changes are easy to integrate (plug and play)
- Plug-and-play Links to change size/length of 3DoF
- Plug-and-play HEADS to fulfill different tasks (picking, marking,…)
- Plug-and-play Motors and other equipment (adapt strength/precision/speed)
Inexpensive/reusable HW:
- Usage of standard motors (steppers, drivers) that can be reused
- Usage of Profile system (reusable, simple addition/changes)
ROS2 Interface to modularize/standardize system
- Plug and play Nucleo STM32 Interface and build system
- ROS2 and SW Modules to easily change Motors/Drivers/Sensors
Object detection for tracing and picking object
- OpenCL to detect incoming objects on any unknown 3D trajectory and to follow objects with head
- Object classification to check detected objects are valid items (DPU ML Core with accellerator)
- Machine learning pipeline to simply add new objects for detection
The image shows the following components:
- ‘A’ : 3DoF robotic arm - rotation link
- ‘B’ : 3DoF robotic arm - lower link
- ‘C’ : 3DoF robotic arm - upper link
- ‘D’ : 3DoF robotic arm - Attachable head/gripper with camera (to follow target when locked on target)
- ‘E’ : Linear 2-Axis system - Linear rail X movement
- ‘F’ : Linear 2-Axis system - Linear rail Z movement
- ‘G’ : Object trajectory camera
- ‘H’ : Object trajectory field
- ‘I’ : Object interaction field
The Hardware consists of 3 main systems: The 3DoF Robotic arm, the camera module to track/detect incomming objects and for test/debug purposes the debug linear axis system
The idea is that when an objects passes field ‘H’ in any trajectory towards field ‘I’ then the camera detects the objects trajectory and velocity and calculates the optimal interception path for the 3DoF robotic arm.
To emulate/train/debug different trajectories with high precision the linear 2-axis system is used. Here the user can program trajectories completely decoupled of the ML robotic system.
Here is a view on the actual complete implementation (with current issues on the HEAD part as one may see...)
The software is distributed on 3 different systems: Host PC for compile time tasks like compilation, ml-inference and debugging and monitoring, Nucleo64-F446RE board for controlling the robotic arms (both 3DoF arm and linear 2-axis) and the Kria KR260 FPGA board for all kind of runtime processes like object detection, machine-learning, trajectory calculation ect.
FUTURE: Right now all the ROS2 and debug system (excluding all DPU/ML features) run on Kria Ubuntu system and must be ported to Petalinux NOTE: This section will not explain how this systems are used. Please refer to the ‘HOWTO’ section.
2.2.1. Object inference (Learning new objects)For learning to detect new objects to the 3DoF system, a complete workflow is given for inference of the object classification system. The user has to film the object from different angles. This video (.mp4) will be automatically split and prepared for inference with the ‘Video Converter’. When the images are prepared, an automated google colab pipeline ‘ML inference firmware’ uses those images to relearn the machine learning model. The current model used for inference is the ‘mobilenetv2’ model trained with the ‘imagenet’ dataset. When the .h5 floating point model is ready, it will be passed to automated ‘Vitis AI Tool compile flow’ for quantization and compilation (adapt to the actual DPU Core architecture). Then the machine is able to detect those new objects.
FUTURE: Automate the whole flow inside vitis-ai, if possible on the target hardware including making the video with the 3DoF arm. FUTURE: Right now only the original model compiles with vitis-ai because of an layer problem. Fix the layer problem
2.3. Object detection and classificationWhen an object enters the ‘Movement Area’ then it is detected by the ‘OpenGL trajectory calculator’ and creates an image for every object it detects. The ‘ML classificator controller’ checks the images and returns a ‘object [not] detected’ to the ‘OpenCL trajectory calculator’. When the object is detected, The ‘OpenCL trajector calculator’ calculates the trajectory and velocity and position of the object. This is passed to the ‘3DoF Movement Controller’ which will calculate and deploy the optimal interception trajectory for the 3DoF robot arm.
Once the 3DoF robot arm reaches the object, the control is passed to the ‘OpenCL Object follower’ which gets its videos from the 3DoF robot arm video CAM and returns the correction parameters to follow the object on the move. Linearization and rotational correction is done in the ‘3DoF Movement Controller’.
The ‘3DoF Movement Controller’ directly outputs the absolute position of stepper-increments for the stepper motors on every axis. This information is transmittet via the ROS2 Publisher with a custom ROS2 message.
2.4. 3DoF Robot and Linear 2(3) AxisThe 3DoF Robot system is a modular robot arm which two ~20 cm links and one rotation base adding to 3 stepper motors and 3 limit-switches for position calibration (‘Stepper Driver + POS’). The robot gets its position from the Nucleo board. The head of the 3DoF robot arm includes a gripper, a positional correction unit (4th link to correct gripper orientation) and a camera to follow the object once it intercepts the object in motion. The position unit and the gripper each have a servo-motor. One of the greatest features of this system is, that each link can be replaces easily plug and play. The links itself are cost optimized and build for modularization.
The linear 2-Axis system is used to program highly repeatable and customizable trajectories for testing and learning of the actual system. In the production ready system this system will not be there. The linear model has 2 stepper motors and 2 limit-switches for position calibration. Those are handled by the nucleo board.
This Nucleo board has a custom software with two modules. First is the ‘Position CTRL + Stepper Driver’ wich compares the actual position of each axis with the incomming new axis position. On difference it controls the servo motors until the position matches. This component also includes a calibration unit to reset the axis position on startup. Additionally the servo motors PWM values are set. The second module is the communication handler, a ROS2 Subscriber to the custom ROS2 message coming from either the HOST-PC or the Kria KR260 board.
Both robot systems are right now controlled over a debugging interface (GUI) which can be installed on the HOST-PC or the Kria KR260 board.
The software for the Nucleo board can be compiled with an custom Makefile flow included in the project. This includes changing the custom ROS2 message.
FUTURE: Control vector for axis and servos comes from ‘3DoF Movement Controller’
2.4.1. Special features of the SystemThe belt system is designed to be silent and cheap and flexible. Therefore a GT2 system is used which is standard for most 3D printers.
The camera module has the ability to change the focus by turning the lens, once opened. For the gripper the focus is set to very near/macro position. For the other camera, the focus is on factory setting
This are the electronics. The connection table for the software is given in the download '<rth>/embedded/connection_table'
Finally the system is designed for plug-and-play. Meaning the links on the 3DoF can be changed very easily by only removing two screws.
3. BOM3.1. Used ToolsThis is a list of used tools and where they where used:
- Blender: Generate 3D Graphic of Hardware. Plan the 3DoF System and the 2Axis System
- STM32 Qube: Plan the NUCLEO64-F446RE pinout and configuration and generate basic STM32 Makefile flow
- Vivado 2022.2: Generate the FPGA Image with Processing system and DPU Core
- Vitis 2022.2: Design the ‘3DoF Movement controller’ and the ‘ML Classification controller’. There is work to be done!
- Petalinux 2022.2: Generated Linux image for DPU Core and PS.
- Vitis-AI Github repository: Compile ML-model for DPU
- KR260 Ubuntu 22.04 Image: First image to get things running fast. Including KRS/ROS2.
- ROS2 Humble + Kria KRS: Use ROS2 system to generate commpunication between embedded HW (Nucleo64) and Processing System (HostPC/Raspberry, later KR260)
- Raspberry PI : As early ROS2 testing system
- Google Colab: Inference for ML
- Other tools : Ubuntu 22.04, docker, BaseTech Power supply (12V, ~ 1A)
Overview of the hardware system including the movement detection camera, 3DoF arm and 2-axis debug system:
Note: All length dimension are in ‘mm’!
3.2.1. Linear 2-axis debug Hardware:Please see on ‘Full system’ graphic!
This section is for developers using the project. It will be explained how to install/build and use the system.
Every hardware you need to get is listed in ‘BOM’ section.
Additionally most of this commands below, if not otherwise noted, are built with an UBUNTU 22.04 image on a basic x86 architecture. For most of the commands you will need a ‘bash’ shell and and ‘apt’ package manager. This might work in windows WSL, but was never tested. So you are on your own if you try.
The following software must be installed
sudo apt install -y git make docker
4.1. Object detectorThis section discusses on how to install and use the object detectors. Specifically the 'OpenGL Object follower' and the 'OpenGL trajectory calculator'.
Note that those systems use the same basis of software since they both track the object, get its median position and calculate from the previous image how much the object moved in what direction.
Before you start: Install Ubuntu 22.04 on your Kria board!
For information see here f.e.: link
After installation please update your Ubuntu system to the latest software.
When you connect to the Kria board via ETH, please make sure to have the GUI/X mode active
ssh -X ubuntu@<ip>
To install the systems simply copy the files to your Kria KR260 Ubuntu home directory
scp <rth>/ubuntu_software/* ubuntu@<kria_ip>:/home/ubuntu/
This will copy the Makefile and the OpenGL software to detect the objects
Lets take a look at the Makefile:
trajectory:
python3 traj_plan/velpos_object_detect.py
gripper:
python3 traj_plan/gripper_detector.py
First connect your webcam to one of the USB ports on your KR260 board.
On the Kria board at the Makefile directory type
'make trajectory'
This should open a window like the following.
Here you can see a green bottle cap that is recognized by OpenGL. You can see this (bad to see in the image) by the red/green circle around the object.
The output of every image is the position and the velocity of the detected object which will be printed to the console in this example.
To change the object of detection the following parameters can currently be changed at the top of file
# Open file and check params on top
vi traj_plan/velpos_object_detect.py
1. hue: The color the object is made of. See HUE diagrams online to find the right value. here 85 is used for the caps green value
2. FrameTimeMS : Update Time (rate) of the images. This must be higher then the cams according fps value. Right now every 100ms a frame is processed. Note that for faster object this must be higher, for slower object slower!
3. draw_min/max_area: The minimum and maximum pixels the object can be. This can be used to filter bigger or smaller objects.
4.2. Embedded software (Nucleo64)Lets start to build the Nucleo firmware.
NOTE: Building the ROS2 workspace for STM32 and Kria is a rather tedious task. There are good tutorials out there you can use to understand whats going on, but this is not a step-by-step/line-by-line copy paste tutorial. This section will fill the missing gaps and the source code. Tutorials are linked below.
The Nucleo board communicates with ROS2 protocol with either the PC or the Kria board. To use the ROS2 protocol on the Nucleo board (over UART) a micro-ros-agent is necessary (handles communicaton for micro-controller devices) and the Nucleo build flow must be adapted to fit.
While the actual system should run on the KR260 board communicating with the Nucleo board, the first system we build is between the HostPC and the Nucleo board.
4.2.1. Installation process for STM32 and ROS2There are three things we need to do:
- Install ROS2 humble on the Host-PC
- Build the STM32 Nucleo compile flow to fit with ROS2
- Build the micro-ros-agent.
The official installation instruction of the ROS2 installation is here link There is a rather lengthy installation process for the ROS2 with micro-ros-agent. The official installation instructions of the micro-ros system are here : link
There is a good introduction on how to install everything with STM32 Nucleo boards on youtube from ‘Robotics in a Nutshell’ : link.
In both cases please note the following:
- All versions of ROS2 must be HUMBLE!
- The board type must be NUCLEOF446RE
- Use my /embedded/nucleo_humble/Makefile
- I adapted the Boards configuration. Please use: /embedded/nucleo_humble/ros2-app1.ioc as Nucleo configuration
- Use ‘embedded/uros_ws’ for the ROS2 local system (see below)
- Use ‘embedded/nucleo_humble’ for the Nucleo compiler (see below)
After you followed the instructions you can start adapting/copy paste the changes.
My folder structure of the files attached in ‘/embedded’ is as follows:
- nucleo_humble: directory for the stm32 compiler with ROS2
- nucleo_humble/core/src/freertos.c : Most of the source code of the Nucleo board is in here.
- nucleo_humble/Makefile : Main Makefile to build the Nucleo board.
- Makefile : My Makefile that collects a couple of useful commands, f.e. Build and deploy flash to Nucleo board or rebuild robot_msgs and applications…
- nucleo_humble/micro_ros_stm32cubemx_utils : robot_msgs also provided for the cubemx compiler. (copy paste after installation)
- nucleo_humble/ros2-app1.ioc: CubeMX configuration file for this projects pinout ect.
- uros_ws/src/app1_package : All GUI applications to control the Nucleo board/axis per GUI
- uros_ws/src/robot_msgs: Custom made ROS2 message to communicate the Axis and Servo positions. (Note that these must also be copied to the micro_ros_stm32cubemx_utils when changed here)
The system uses a custom ROS2 msg called 'robot_msgs' to communicate. This message is shown here:
int32 timestamp
int32 angular0
int32 angular1
int32 angular2
int32 servo0
int32 servo1
int32 axis0
int32 axis1
int32 axis2
This message must be built. When you created a standard ROS2 project (in my case uros_ws) then copy ‘/embedded/uros_ws/src/app1_package’ and ‘/embedded/uros_ws/src/robot_msgs’ to your ROS2 workspace.
4.2.2. Build the Nucleo firmware and flashLets build and program the application to the Nucleo Board.
cd <rth>/embedded
source /opt/ros/humble/setup.sh
make compile
# which executes:
# cd nucleo_humble && make
This should rebuild the whole nucleo application. If you want to change the software, change in the freertos.c file.
If that is done, the program can be flashed. Now connect your Nucleo board to the USB and do the following
cd <rth>/embedded
source /opt/ros/humble/setup.sh
make flash
# which executes
# openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c"program nucleo_humble/build/ros2-app1.elf verify reset exit"
If everything went fine, your Nucleo is now flashed!
4.2.3. Build the robot_msgs and applicationsNow we can build and flash the robot_msgs and applications.
The ‘/emebedded/Makefile’ gives the commands to do this fast and easy (Please adopt the path in the Makefile before you use it!):
cd <rth>/embedded
source /opt/ros/humble/setup.sh
source uros_ws/install/local_setup.sh
make package
# This executes:
# cd uros_ws && colcon build --packages-select robot_msgs --allow-overriding robot_msgs
# cd uros_ws && colcon build --packages-select app1_package --allow-overriding app1_package
This shoud give you ‘colcon build successfull’. Now you have to source the newly create packages
source uros_ws/install/local_setup.sh
When you now use
ros2 pkg list | grep app1_package
the package should exist.
4.2.4. Test the Debug Movement Controller (GUI)When you flashed the Nucleo board and you compiled the ROS2 app and robot_msgs you are ready to test the debug app.
Apply power to all systems. Then we can start with…
cd <rth>/embedded
source /opt/ros/humble/setup.sh;
source uros_ws/install/local_setup.sh
make agent
# which executes
# ros2 run micro_ros_agent micro_ros_agent serial -b 115200 --dev /dev/ttyACM0
After you started the agent, you have to reconnect/restart your nucleo board!!
Now we start the gui debug system
cd <rth>/embedded
source /opt/ros/humble/setup.sh;
source uros_ws/install/local_setup.sh
ros2 run app1_package guictrl
This should result in the following window:
With this window you now can control all links yourself with the sliders.
4.2.5. Install everything on the Kria SystemThe task is to move the ‘ROS2 Micro ROS Agent’ and the ‘Debug Movement Controller (GUI)’ to the Kria board from the Host-PC.
In theory the whole system needs cross compilation. But the humble system can be installed on the ubuntu 22.04 Kria image as simple as on the Host-PC. Also the Micro ros agent can be compiled on the host system. Adding the app1_package and robot_msgs to a new workspace on the Kria humble ROS2 system should be straight forward.
To install the agent, simply follow the same instructions as above. It should work as it did for my purpose.
Simply copy the ‘uros_ws/src/app1_package’ to the new workspace on your kria board, f.e. ‘ros2_ws/src/’(Dont forget the robot_msgs) and recompile them with the instructions in the Makefile.
Source your ros scripts, start the agent, connect everything and start the app. When you are connected with ’ssh -X ’ the debug App should work on the kria like on your Host-PC. If this works, you can create any software to control the Robot system yourself. Congratulations.
NOTE: The Nucleo compilation is always on my Host-PC!
4.3. Create DPU CORE SystemAs the KR260 Ubuntu image has no inbuilt app yet with an working DPU core, and copying the KV260 apps to KR260 and executing those fpga-images might maybe work (with a lot of luck) or damage the fpga (how to know if an active hdmi ect. has opposite directions in the image??) the only solution for me was to try to build the dpu core with petalinux myself.
To create a specific DPU Core and Petalinux build as well as a vitis platform I followed this tutorials:
Here is the thing: This scripts kind of work to create the vitis core, petalinux build and validate the DPU Core works on the target platform (DPU core validation worked on my platform…). But they do not show you how to create an extensible Platform for your Vitis System to compile scripts to run the execution of the machine learning system. Therefore I started to get deeper into vitis platform stuff for KV260. In the end I landed here:
2022.1 Vitis Platform Creation Tutorials
Now, following the steps without recreating the whole petalinux flow and vivado flow, I could not create useful outputs yet. Specifically the VADD example app was missing in my Vitis Platform.
Time ran out. My best guess right now is either that I have to adapt the Vivado System since those upper tutorials and this one is not exactly the same regarding to PS, clocks and DPU or that my KR260 platform simply has no example app with VADD.
Therefore there is actually work to be done.
4.4. Inference of ObjectsThis section explains how to add new objects to be detected by the system.
Prepare learning imagesThe idea is to make a video from your object from different angles. Then split and resize the video into separate pictures, rename them for ML and use them in the Inference process.
I have two objects called ‘bottlecap’ and ‘pencap’.
Store an image of your object in /inference/data/<obj_name>.mp4
Create directory for pics /inference/data/<obj_name>.mp4
Then adapt the following script (located in /inference/Makefile):
OBJ_NAME:=pencap
decode-video:
ffmpeg -i data/${OBJ_NAME}.mp4 -vf "crop=1080:1080,scale=225:255" -r 5.0 data/${OBJ_NAME}/${OBJ_NAME}_%05d.png
Finally execute the script:
cd <robotic-third-hand>/inference
make decode-video
This splits the video into small images prepared for machine learning.
NOTE: In my actual example you need two different objects. F.e. I have a pencap and a bottlecap. NOTE: Make sure your images have good light conditions and are centered all the time. Delete bad image per hand afterwards…
Examples of my learning pictures from the video:
In this section we use the two different objects pictures (In my example a pencap and a bottlecap, see above)
This is done in google colab. First make an account if you do not have one. In the colab environment click on the left ‘Folder’ symbol. A tab opens. In this tab click on the Folder symbol with the two dots ‘..’. Now you should see a rootfile system like in a linux system.
Upload data to colab (f.e.): /content/drive/MyDrive/dataset_caps1/bottlecaps/.png /content/drive/MyDrive/dataset_caps1/pencaps/.png
Next upload the Notebook to colab with ‘File/Upload Notebook’ (You can also use the python file, but this is not tested yet): /inference/inference_caps_resnetv2.ipnb
NOTE: If your data/object is named different/in different directories, rename also the ‘DataSetPath’ in this script! NOTE: Before you execute the script change to GPU (if accessible, this will speed up the process): ‘Runtime/Change runtime type’ with Hardware Accelerator = T4 GPU
Run the whole script with: ‘Runtime/Run all’
This should generate 2 output .h5 models.
"/root/home/models/model_caps_imagenet_mobilenetv2.h5" = newly trained model with our caps
"/root/home/models/model_imagenet_mobilenetv2.h5" = original trained mobilenetv2 model.
If everything run well you should see a in the last cell a matrix with 4x4 pics with their respective regression. within this model there are actually only two outputs. ‘Object to pic’ with < 0.5 and ‘Objects not to pic’ with >=0.5 Respective the pencap has > 0.5 and the bottlecap has < 0.5. This can be seen in the following image:
How good your model performs depends on a lot of factors including image quality and object features. A characteristic of how good your object can be detected can be seen in this graphic that will also be generated:
In this tutorial we compile the model we have learned to detect objects to be used by the FPGA DPU Core.
NOTE: As of now, the trained model can not be used for compilation. There is still an error in the layer selection. For testing purposes we therefore use the original model which was stored alongside the inferred model.
First install the Vitis-AI tool from gitlab and checkout the latest branch
git clone https://github.com/Xilinx/Vitis-AI.git
cd Vitis-AI
git checkout master
Download the docker image for the Vitis-ai system
docker pull xilinx/vitis-ai-tensorflow-cpu
Copy the directory with the build scripts and the previously built google colab machine learning model
cp <rth>/vai/* <vitis-ai>/mymodel/
cp <google colab model_imagenet_mobilenetv2.h5> <vitis-ai>/mymodel/mobilenetv2_int8.h5
Copy the dpu architecture file from vitis (previous step)
cp <rth/fpga/vivado/*.json <vitis-ai>/mymodel/arch.json>
Download training dataset for imagenet. This will be needed for testing the compilation.
F.e. https://www.kaggle.com/datasets/akash2sharma/tiny-imagenet
Copy a couple of different phot from different objects (~100) to the folder defined in ‘quantize_model.py :: DataSetPath’
Start the docker image in Vitis-AI and activate the environment
cd <Vitis-AI>
./docker_run.sh
# As of now you are in docker vitis-ai
conda info --envs
conda activate vitis-ai-tensorflow2
cd /workspace/mymodel
For the next couple of steps you can also follow (be aware that the source code in this models in not complete. For working source code see examples of my scripts below):
UG1414 : Vitis AI User guide
- Quantizing the model
- Compiling the model
- Deploying and running the model
Script was deleted. In theory this is not necessary but highly recommended to inspect the model before compilation. I will recreate the script.
4.4.3.2. Quantize the modelExecute the script for quantization
cd <Vitis-AI>/mymodel && mkdir out && python3 quantize_model.py
4.4.3.3. Compile the modelExecute the following command in the 'mymodel' directory
cd <Vitis-AI>/mymodel && vai_c_tensorflow2 -m ./mobilenetv2_int8.h5 -a ./arch.json -o out/ -n netname
When the scripts run without error you should have an xmodel file in the out directory for deploying on your kria KR260 dpu
5. Future work5.1. Changes to original modelThe whole trajectory system only has 2 dimensions to reduce overhead
- Future: Extend the model (Trajectory detection and debug 2-axis system) to third dimension
- The whole trajectory system only has 2 dimensions to reduce overhead
Future: Extend the model (Trajectory detection and debug 2-axis system) to third dimension
The Motors are Stepper motors instead of controlled brushed/brushless motors
- Future: Benchmark higher powered DC motors with control circuit
- The Motors are Stepper motors instead of controlled brushed/brushless motors
Future: Benchmark higher powered DC motors with control circuit
The Cameras are not high speed cameras but 30fps USB cams (Efficient for a first prove of concept)
- Future: Benchmark with high speed camera
- The Cameras are not high speed cameras but 30fps USB cams (Efficient for a first prove of concept)
Future: Benchmark with high speed camera
Split the ML Model from direct object detection into OpenCL object detection and ML object classification
- Future: Try to use direct object-detection for trajectory calculation. This might even be the biggest concern. With OpenCL it is easy to track simple objects. More complex objects might need the Object detection with position extraction anyways.
- Split the ML Model from direct object detection into OpenCL object detection and ML object classification
Future: Try to use direct object-detection for trajectory calculation. This might even be the biggest concern. With OpenCL it is easy to track simple objects. More complex objects might need the Object detection with position extraction anyways.
- Ubuntu 22.04 is the standard platform for all system except all ML-Stuff. If no DPU will be available soon, all systems have to be moved to custom petalinux image.
- Program 3DoF Movement Controller (when ML-Classificator works)
- Program ML-Classificator (only the simple execution script, when Vitis platform example works)
- Vitis-Platform example with custom petalinux and custom dpu-accellerator (Iam on it right NOW!)
- Optimize the 3DoF system for performance and weight. Right now the system is to bulky on some parts.
FUTURE: Right now all the ROS2 and debug system (excluding all DPU/ML features) run on kria ubuntu system and must be ported to petalinux FUTURE: Right now only the original model compiles with vitis-ai because of an layer problem. Fix the layer problem
5.3. Other future projects- Automate the whole Inference flow inside vitis-ai, if possible on the target hardware including making the video with the 3DoF arm.
Quite a lot of lessons learned:
- Ubuntu KR260 has no plug and play DPU model as of yet. Including the ML algorithms has high overhead compared to KV260. KV260 board might be the better choice for now for ML applications.
- ROS2 has some heavy overhead on the STM32 boards. While its a much more professional environment compared to arduino, arduino ROS2 would be maybe the faster choice.
- Never use the dynamic arrays in ROS2. They will not work for some reasons. Always go the extra mile to define a static new ROS2 Message
- If possible checkout the lowest version of ROS2 used in the system. F.e. Kria KR260 ubuntu has ‘humble’ installed. Downgrade takes a lot extra effort.
- Install the right version of AMD tools and do NEVER try to mix petalinux/vitis/vivado/project sources or bsp versions in any way. This will take you a lot of time to rebuild for hours to find out something will not work. I installed vitis-ide with 2023 edition before starting the project. Later I found out that DPU creation only supports 2022.2. So I had, after multiple fails, to downgrade everything to 2022.2.
- Having a functional 3DoF robot arm in HW is a big plus because such systems tend to be very complex to simulate in a realistic way. But regarding time and the amount of money I spend into hardware I would rather use something like ROS2 simulation next time for first try.
- 500Gb might not be enought when you have Vitis platform and do multiple petalinux/vivado projects side by side.
Comments