Asked

Alternative To Ezrobot Ezb For Robot Head Project

My course has primarily focused on robotics projects using the EZ-B controller and a camera for real-time interfacing. With recent developments, I am planning to create an additional video that incorporates Synthiam's support for other types of controllers. Although I've successfully flashed an alternative controller, it lacked compatibility with camera integration and Wi-Fi capabilities. The absence of an onboard computer limits the use of a USB camera, posing a significant challenge.

This dependency on specific components like the EZ-B, IO Tiny, and cameras can be problematic. For my course project, Mecha Morphix, which involves controlling five servos, the Arduino Mega seems excessive. I am in search of a suitable controller, compatible with Synthiam ARC, that includes both Wi-Fi and camera support to effectively replace the EZ-B.

I noticed that the ESP32 with a camera is listed among the supported controllers for ARC. Has anyone experimented with using the ESP32 in conjunction with a camera for such applications? Any insights or experiences would be appreciated.


Related Hardware ESP32 Cam

ARC Pro

Upgrade to ARC Pro

Unleash your creativity with the power of easy robot programming using Synthiam ARC Pro

Author Avatar
PRO
USA
#153  

Quote:

the thing is - the esp32's aren't multi-threaded so we're sharing the same thread for sending the camera image and processing ezb commands. the i2c is even slower that wifi so that's a bottleneck as well. i'll think of something....
Just throwing stuff out there.

From internets: Most ESP32 models feature dual-core processors (Core 0 and Core 1), enabling true, simultaneous execution of tasks, or the use of single-core multitasking via time-slicing.

xTaskCreatePinnedToCore: This function allows developers to assign specific tasks to a particular core (Core 0 or Core 1) to manage resource usage.

Author Avatar
PRO
Synthiam
#154  

thanks! multi cores and threaded doesn't work the way ppl think it does when objects and peripherals are shared. so when i said the single threaded makes it difficult - that's mostly referring to how the esp32 and all microcontrollers share resources. technically, the real way it "could" work is if it was 3 cores haha. because one could be acting as the tcp stack wifi driver. but anyway, i have a solution without the overhead of time slicing.

remember, the camera is blocking i/o not the cpu - which is also the biggest factor.

so my new code i wrote should solve the issue... at least, i think so. i'll have to publish it later after the new ARC release. we have an ARC release planned this monday but i'm gonna squeeze in a few changes into it for firmwares.

Author Avatar
PRO
USA
#155  

Brilliant! Thanks for all the hard work! Looking forward to testing. Have a good rest of your weekend.