Hi GR, very impressed with the results you achieved with vision + ultrasound sensors! Great job! I remembered that I had accidentally watched the demo you posted on youtube earlier, but hadn't really looked into your code.
Your preference for vision-based algorithms is understandable given the function you are trying to achieve, which is to identify and pick up lego parts that are scattered all over the place. I can even think of another sbc, beagley-ai, that would be particularly suitable for your scenario, perhaps replacing your current PC node.
Yes, the robot I wanted to build is very similar to yours in final form. But at the moment my work is focused on porting micro-ros to build HAT. When it comes to middleware, I'm probably going to stick with ros2 as a target as planned. Even I have no previous experience with robotics development, but it looks like ros2 is a de facto standard, so I thought it was worth a try.
Later on, when I'm working on the motor driver, I might need to take a closer look at the part of your code for motor controlling. My current thinking is that the pid controller will be implemented in the build HAT firmware, in the form of a ros node. Maybe then our work might converge, and we'll see what we can do, as far as build HAT/motor drivers are concerned.
Build HAT's problem with motor pair control, as described in the link you provided, I suspect is due to processing efficiency. The Build HAT firmware is implemented as a grand loop, where each loop iteration processes one port, and if the processing of the previous port takes too many cpu cycles, the next port will show visible sluggishness. This is my hypothesis. The way you've implemented it seems to confirm what I suspected, since offloading the pid control part to RPI eliminates the problem.
Well, congrats again!! If we have any ideas, or if I have any specific questions for you, we can talk here, or in some other way, okay?
Your preference for vision-based algorithms is understandable given the function you are trying to achieve, which is to identify and pick up lego parts that are scattered all over the place. I can even think of another sbc, beagley-ai, that would be particularly suitable for your scenario, perhaps replacing your current PC node.
Yes, the robot I wanted to build is very similar to yours in final form. But at the moment my work is focused on porting micro-ros to build HAT. When it comes to middleware, I'm probably going to stick with ros2 as a target as planned. Even I have no previous experience with robotics development, but it looks like ros2 is a de facto standard, so I thought it was worth a try.
Later on, when I'm working on the motor driver, I might need to take a closer look at the part of your code for motor controlling. My current thinking is that the pid controller will be implemented in the build HAT firmware, in the form of a ros node. Maybe then our work might converge, and we'll see what we can do, as far as build HAT/motor drivers are concerned.
Build HAT's problem with motor pair control, as described in the link you provided, I suspect is due to processing efficiency. The Build HAT firmware is implemented as a grand loop, where each loop iteration processes one port, and if the processing of the previous port takes too many cpu cycles, the next port will show visible sluggishness. This is my hypothesis. The way you've implemented it seems to confirm what I suspected, since offloading the pid control part to RPI eliminates the problem.
Well, congrats again!! If we have any ideas, or if I have any specific questions for you, we can talk here, or in some other way, okay?
Statistics: Posted by muzkr — Mon Mar 31, 2025 11:23 am