Has anyone had issues with stability on rough surfaces, such as carpet or sidewalk? I'll post some videos in the comments to show different configurations of surface and foot surface

In skill creation: https://docs.petoi.com/applications/skill-creation It is specified that the limit for joint servos is -125-125 degrees, but says if an angle outside of this range is necessary, the angle ratio can be adjusted. Is there a physical limit on the servos, or can they be programmed to rotate 360 degrees?

Hello everyone, I'm excited to share my experiences and insights on video streaming capabilities when using Bittle in combination with a Raspberry Pi. I've explored two methods to achieve this, each with its own set of advantages and technical considerations. Method 1: Python with Socket Protocol and OpenCV • Overview: Leveraging Python, along with the socket protocol and OpenCV, I developed a streamlined process for video streaming. • Repository & Configuration: For those interested in the technical specifics or looking to replicate this setup, you can find the details in my GitHub repository here. It includes all necessary Raspberry Pi configurations to integrate seamlessly with the NyBoard. Method 2: ROS2 Integration • Overview: Adopting ROS2, I focused on publishing and subscribing to topics for video streaming. • ROS2 Package: The repository for the ROS2 package can be found here. This package is based on instructions originally designed for ROS Melodic, detailed here. • Technical Journey: Inspired by the bittle_driver.py in the Melodic repository, I ventured into creating a compatible ROS2 package using ROS2 Humble. My preference for the Raspberry Pi camera led me to explore additional ROS2 packages, culminating in the adaptation of the ROS2 Bittle package for video streaming, guided by this article. Performance and Configuration Both methods have demonstrated effectiveness, with the quality of video streaming being closely tied to the configuration of image capture and compression. My experiments were primarily conducted on Raspberry Pi Zero 2W and Raspberry Pi 4 platforms. While I have not quantified the frame rate for the socket-based Python approach due to its limitations for this application, the ROS2 framework has consistently delivered superior video quality. Achievable Frame Rates: • Raspberry Pi Zero 2W: High 20s per second, achievable through specific launch file configurations (detailed below). • Raspberry Pi 4: Low 30s per second, with jpeg quality set at 40%. Sample Launch file (robot_joystic_launch.py): from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( package='bittle_ros2', executable='joystick_driver', name='main_module', output='screen' ), Node( package='v4l2_camera', executable='v4l2_camera_node', name='camera', output='screen', parameters=[ {'video_device': '/dev/video0'}, {'output_encoding': 'rgb8'}, {'pixel_format': 'YUYV'}, {'image_size': [640,480]}, {'io_method': 'mmap'}, {'image_raw.jpeg_quality' : 25} ] ) ]) Challenges and Ongoing Troubleshooting Despite achieving satisfactory frame rates, I've encountered intermittent drops in frame rate, leading to sporadic choppy video feeds. Identifying the exact cause remains a challenge, with no clear correlation observed between network I/O, CPU usage, and video quality. An important consideration for Raspberry Pi 4 users is the inadequate voltage supply from the NyBoard, potentially leading to system crashes. A workaround involving a custom wiring a voltage regulator from the + and - terminals on the NyBoard to the GPIO pins on the Rasberry Pi has been my solution. Next Steps Updates and breakthroughs will be shared in this forum. I hope this framework serves as a solid starting point for those looking to explore video streaming capabilities on their robotic projects. Your feedback and contributions are highly welcomed.

I'm trying to utilize some of the unused servo ports on the NyBoard to add additional functionality to Bittle. I have one servo hooked up to port 0 (the head port), and one hooked up to port 2 (where the tail would be connected). I have two questions: 1) For the servo connected to port 2, I have defined this skill: const int8_t pher[] PROGMEM = { -2, 0, 0, 1,  0, 0, 0,   0, -80,  -90,   0,  0,  -3,   3,   3,  75,  75,  75,  75, -55, -55, -55, -55,  4, 0, 0, 0,   0, -80,    0,   0,  0,  -3,   3,   3,  75,  75,  75,  75, -55, -55, -55, -55, 4, 0, 0, 0,   }; Which is located in InstinctBittle.h. The strange thing, is that when I call this new skill, sometimes the servo moves counter clockwise, and sometimes clockwise. Is there a way to ensure the servo moves in the same direction each time? 2) For the servo connected to port 0, whenever Bittle does any other action such as walking, crawling, etc., the servo moves a few degrees back and forth. I have changed all the other skills in InstinctBittle.h to have 0 for the angle of port 0, however this didn't do anything. Is this oscillation defined somewhere else for this port that I can adjust to eliminate this behavior?

I made a ROS2 package for Bittle. I took the existing library that was made using ROS Melodic in this hackster article: https://www.hackster.io/dmitrywat/bittle-teleoperation-with-ros-and-raspberry-pi-22c454(https://www.hackster.io/dmitrywat/bittle-teleoperation-with-ros-and-raspberry-pi-22c454) It is a work in progress, presently I have only implemented remote control from a desktop. I am going to be adding video streaming in the near future. Here is the link to the repository: https://github.com/gravesreid/bittle_ros2/tree/main(https://github.com/gravesreid/bittle_ros2/tree/main)

I'm working on adjusting custom commands for use in the ardSerial.py (http://ardSerial.py)and example.py (http://example.py)scripts. Just looking for clarification on the individual parameters. As an example, the crawl forward command from InstinctBittle.h is defined as: const int8_t crF[] PROGMEM = { 34, 0, 2, 1, 42, 73, 83, 75, -43, -42, -49, -41, 37, 75, 78, 77, -41, -41, -50, -41, 36, 78, 73, 80, -38, -41, -50, -41, 37, 81, 68, 82, -36, -41, -50, -40, 41, 83, 62, 85, -36, -40, -48, -40, 42, 88, 57, 85, -36, -40, -47, -39, 45, 92, 51, 88, -37, -44, -44, -38, 48, 91, 50, 90, -38, -45, -41, -37, 51, 89, 55, 91, -39, -48, -40, -36, 53, 84, 55, 93, -40, -49, -40, -35, 56, 80, 58, 99, -40, -50, -41, -37, 59, 75, 61, 101, -41, -50, -41, -40, 62, 69, 64, 101, -41, -50, -41, -42, 64, 64, 65, 99, -41, -49, -41, -44, 67, 58, 68, 95, -42, -48, -42, -46, 70, 53, 71, 92, -42, -47, -42, -47, 73, 48, 74, 88, -42, -45, -41, -48, 74, 42, 75, 83, -41, -43, -41, -49, 77, 37, 78, 78, -41, -41, -41, -50, 80, 36, 81, 73, -41, -38, -41, -50, 82, 37, 83, 68, -40, -36, -40, -50, 85, 41, 85, 62, -40, -36, -40, -48, 89, 42, 87, 57, -41, -36, -39, -47, 93, 45, 89, 51, -45, -37, -38, -44, 92, 48, 91, 50, -47, -38, -37, -41, 88, 51, 93, 55, -48, -39, -36, -40, 83, 53, 96, 55, -49, -40, -35, -40, 78, 56, 100, 58, -50, -40, -38, -41, 73, 59, 102, 61, -50, -41, -42, -41, 68, 62, 99, 64, -50, -41, -43, -41, 62, 64, 96, 65, -48, -41, -45, -41, 57, 67, 93, 68, -47, -42, -47, -42, 51, 70, 89, 71, -46, -42, -48, -42, 46, 73, 84, 74, -45, -42, -49, -41, }; And I believe the first entry on the first column represents the number of lines in the command, and the last line is related to the time of the command in some way, but I'm not sure what this time corresponds to exactly. I don'n know what the second and third entry in this line do. The subsequent lines with 8 columns are the servo angles. For the line entry, it appears that if a negative sign is placed in front, the command executes once without repeating, where as normally it would execute until receiving a new command. For the skills like sit: const int8_t sit[] PROGMEM = { 1, 0, -30, 1, 0, 0, -45, 0, -5, -5, 20, 20, 45, 45, 105, 105, 45, 45, -45, -45,}; I'm not sure what the first 8 commands do, but the last 8 correspond to the servo angles. On the first line, what does the -30 correspond to? Is this the head angle?

Is there a simple way to send a command in ardSerial.py (http://ardSerial.py)to execute a movement command like walk or crawl, and to have Bittle rest immediately after execution? So if I send "kwkF", instead of walking until I send it another command, can I have Bittle execute "krest" or "ksit" once it has completed one iteration of the walk movement?

I have been having trouble running serial commands with Raspberry PI. I have followed the instructions here: https://docs.petoi.com/apis/raspberry-pi-serial-port-as-an-interface (https://docs.petoi.com/apis/raspberry-pi-serial-port-as-an-interface) -Login Shell over serial monitor is disabled -Serial port hardware is enabled -One wire interface is disabled I have cloned the opencat repository to the pi, and here is the output when I run ardSerial.py:(http://ardSerial.py) pi@raspberrypi:~/OpenCat/serialMaster $ ./ardSerial.py(http://ardSerial.py) ardSerial date:  Oct 10, 2023 *** Available serial ports: *** /dev/ttyS0 Waiting for the robot to boot up No port found! Please make sure the serial port can be recognized by the computer first. Replug mode Please disconnect and reconnect the device from the COMPUTER side 2023-11-08 09:25:30,275 main - INFO - Exception Traceback (most recent call last):   File "/home/pi/OpenCat/serialMaster/./ardSerial.py", line 885, in <module>     raise e   File "/home/pi/OpenCat/serialMaster/./ardSerial.py", line 862, in <module>     connectPort(goodPorts)   File "/home/pi/OpenCat/serialMaster/./ardSerial.py", line 701, in connectPort     replug(PortList, needSendTask)   File "/home/pi/OpenCat/serialMaster/./ardSerial.py", line 713, in replug     window = tk.Tk((http://tk.Tk))              ^^^^^^^   File "/usr/lib/python3.11/tkinter/__init__.py", line 2326, in init     self.tk (http://self.tk)= _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ _tkinter.TclError: no display name and no $DISPLAY environment variable * Port ttyS0 is not connected to a Petoi device! I have verified that the switch on the back of the Nyboard is set to Rpi, and I have verified good continuity between the connections on the back of the Pi to the back of the Nyboard. None of the pins are shorted. I have also verified that I can control the GPIO pins on the Pi with a simple LED control python script with a breadboard. I can run the ardSerial.py (http://ardSerial.py)and example.py (http://example.py)if I set the Nyboard to Arduino and connect the Pi and Nyboard through micro usb. Does anyone have experience with this issue?