Not within imu.h without throwing missing definition errors, but adding io.h to the include statements causes multiple declaration errors. It was simpler to just add the Serial2 print statement.

I tried that initially, however that caused a chain of changes I would have to make to the codebase, which I am hesitant to implement at the risk of breaking something else. My temporary solution is: void print6Axis() {   String data = String(ypr[0], 2) + "\t" + String(ypr[1], 2) + "\t" + String(ypr[2], 2); #ifdef READ_ACCELERATION   data += "\t" + String(*xyzReal[0]) + "\t" + String(*xyzReal[1]) + "\t" + String(*xyzReal[2]) + "\t" + String(aaWorld.z); #endif   Serial.println(data);   Serial2.println(data); }

I've gotten the serial monitor to work on both USB and UART2 with the XS command. I'm having trouble getting the IMU data to send to my raspberry pi through the "v" command though. When I enter "v" through the raspberry pi, the IMU data is printed on the arduino IDE serial monitor, but not on the PI. Do you have any insight on this?

I found that adjusting the setup loop in the OpenCatEsp32.ino code: From this: void setup() {   // put your setup code here, to run once:   Serial.begin(115200);  // USB serial   Serial.setTimeout(SERIAL_TIMEOUT);   // Serial1.begin(115200); //second serial port   while (Serial.available() && Serial.read())     ;  // empty buffer   initRobot(); } To this: void setup() {   // put your setup code here, to run once:   Serial.begin(115200, SERIAL_8N1, 16, 17);  // USB serial   Serial.setTimeout(SERIAL_TIMEOUT);   // Serial1.begin(115200); //second serial port   while (Serial.available() && Serial.read())     ;  // empty buffer   initRobot(); } Got the serial communication to the Tx and Rx pins to work

Following up on this post, I'm still trying to get the Tx and Rx pins on the ESP32 to work for serial communication with a raspberry pi. I've noticed that the OpenCatEsp32.ino file has this in the setup loop: void setup() {   // put your setup code here, to run once:   Serial.begin(115200);  // USB serial   Serial.setTimeout(SERIAL_TIMEOUT);   // Serial1.begin(115200); //second serial port   while (Serial.available() && Serial.read())     ;  // empty buffer   initRobot(); } Where the line that is commented out has a comment that this is for the second serial port, while the first Serial.begin statement is commented to be for the USB serial. I tried removing the comment, however the board is unresponsive when I do this. Additionally, I've been able to test the serial communication with this .ino file: void setup() { Serial.begin(115200); // Initialize Serial for debugging Serial2.begin(4800, SERIAL_8N1, 16, 17); // Initialize Serial2 with a lower baud rate Serial.println("Serial2 test started"); } void loop() { if (Serial2.available()) { String incoming = Serial2.readStringUntil('\n'); Serial.print("Received from Pi: "); Serial.println(incoming); // Send a response back to the Raspberry Pi Serial2.print("Hello from ESP32\n"); } delay(1000); } and this python script running the on the Raspberry Pi: import serial import time # Configure the serial port ser = serial.Serial( port='/dev/serial0', # Use the correct serial port for your setup baudrate=4800, # Lower baud rate timeout=1 ) def main(): time.sleep(2) # Give some time for the connection to establish print("Starting Serial communication with ESP32") while True: # Send a message to the ESP32 ser.write(b'Hello from Raspberry Pi\n') print("Sent: Hello from Raspberry Pi") # Wait for a response from the ESP32 response = ser.readline().decode('utf-8').strip() if response: print(f"Received: {response}") else: print("No response received") time.sleep(1) # Delay before the next message if __name__ == "__main__": main() This test worked as expected to communicate using the Tx and Rx pins on the Pi and Esp32. I'm just having trouble tracking down where in the OpenCatESP32 code I need to adjust things to get commands working with this port.

Yes, the switch is set to UART2

This is what it does:

That was the problem. I figured it out like 2 minutes after I submitted this post for approval 😂.

Thanks Alex!

Thank you! I've had so much fun working with Bittle, I am eager to keep exploring what can be done with the platform.

I see, it looks like the ESP32 is the way to go. But I'd like to still use the raspberry pi for ROS2 interfacing. Basically, I have the high level planning, such as overall heading in ROS2, but have the adaptive balance correction on the ESP32, if that makes sense.

What are the limitations of the gyroscope correction to joint angles to maintain the center of mass? Can you direct me to where this is implemented in the source code on the NyBoard? I've also been wondering if further refinement of stability and gait calls for the BiBoard, but I'm curious, do you know if a raspberry pi can interface with it? I gather that it would have to be through USB connection rather than GPIO pins.

I'm intrigued by this: The robot proprioception is demanded to an inertial measurement unit (IMU) and to joint encoders. From Robot Feet, part 2. I wonder what the proprioception limits are of the NyBoard? From a philosophical perspective, you don't need to train a wheel to roll, but every animal needs to learn to walk. My gut feeling is that gait design combined with adaptive control based on sensor input is the way to achieve universal stability.

Is the current gait with the foot sliding used because it is more stable on smooth surfaces?

This is on carpet without friction tape. This is also unstable, but not as bad as with friction tape.

This is on carpet with friction tape on the feet. It is the most unstable configuration

This is on tile without friction tape. It is the most stable configuration.

This is bittle on tile with friction tape on the feet. It is less stable than without friction tape.

Update for Pi Zero 2w: I've found that setting the image size to 320x240 with jpeg_quality at 20 provides low latency streaming.

I'm so glad others are using it!