Introduction: There have been questions and comments at Camp Petoi regarding comparisons between the NyBoard V1 and the BiBoard V0_1 or V0_2.  The context is "Which is better?" but I think the real question is "Which is better for you right now?".  I'd like give my answer to that latter question, based on what I've learned from working first with my Nybble (NyBoard of course) and then by upgrading my Bittle from a NyBoard to a BiBoard V0_2. Let's start with some specifications... • The NyBoard uses an 8-bit Atmel ATMega328 single chip microcontroller that operates with a single core at up to 20 MHz (up to 20 MIPS), same as the Arduino Uno.  An int type consumes 2 bytes to be memory efficient but with a limited range.  It has only 32 KB of flash memory, used for storing program code, and only 2 KB of SRAM, used for storing variables.  The NyBoard is a microcontroller with modest processing power where every byte of memory is precious. • The BiBoard uses a 32-bit Espressif ESP32-WROOM-32D "system on a chip" (SoC) microcontroller that operates with two cores at up to 240 MHz (up to 400 MIPS).  An int type consumes 4 bytes which is less memory efficient but with a wider range.  Furthermore, it is an actual "system" with more features (like built in Bluetooth and WiFi) that further consume memory.  Still, the specific chip (ESP32-DOWD) in the BiBoard has available16 MB of flash memory of which about 4.5 MB can be configured for storing program code AND this chip has approximately 320 KB SRAM available for storing variables.  The BiBoard is a microcontroller with strong processing power where every byte of memory is (relatively) cheap. and then some observations... • The NyBoard is an Arduino Uno compatible which means that the wealth of information on the Arduino Uno will likely directly apply.  This makes the NyBoard a great introduction to microcontroller driven robotics.  It is plenty capable for the current features we see in the Petoi robots.  However, the amount of memory space for code and for variables is, by comparison, limited.  This makes compiling programs faster but puts constraints on what additional features can be added.  Petoi has done amazing work making the OpenCat source code very memory efficient but we are almost out of memory at compile time.  Expansion of robotic capabilities is therefore more difficult with the NyBoard. • The BiBoard is based on a very different architecture so it is not an Arduino Uno compatible.  Furthermore, the Arduino IDE is not natively compatible with ESP32 boards.  Fortunately, as explained on the Petoi website (see https://docs.petoi.com/arduino-ide/upload-sketch-for-biboard ), you can make that IDE compatible with the BiBoard.  In my experience, information on the ESP32 is harder to find and harder to understand when you find it.  That makes the BiBoard more suitable for the hobbyist who has some prior experience with Arduino compatible boards before learning how the ESP32 differs.  Such "system on a chip" (SoC) boards are more complex so their programs are larger and take longer to compile.  The payback you get with the BiBoard is plenty of memory, much more processing power and the OpenCat32 source code that allows easier expansion of robotic capabilities by both the Petoi team and individual Petoi Campers.  with different levels of control you can have over the Petoi robots... • The lowest level of control requires the no programming skill, because it uses the Petoi App for Android or iOS.  This great for play with either board. • The next level of control requires some programming skill through the use of the "block-based" programming environment by Mind+ (See here and here).  The program is composed in the Mind+ graphical user interface on a computer and then serial commands are sent to the robot when the program runs.  With this control, there is still little difference between the NyBoard and the BiBoard. • Still higher control is possible with some coding skill using the Python language.  This involves writing code in Python on a computer that then also sends serial commands to the robot.  With this control as well, there is still little difference between the NyBoard and the BiBoard. • At the highest level of control, you need coding skills in the C++ language using e.g. the Arduino IDE.  Here, you are modifying a local copy of the OpenCat or OpenCat32 source code.  With this level of control, the BiBoard has the advantage due to the memory limitations of the NyBoard. which brings me to these conclusions... • If you mostly want to play with a cool robot then a Bittle with either board is good. • If you are just learning to program and you want to use either "block-based" or Python programming then a Bittle with either board would be good. • If you are just learning to program and you want use the C++ language but stay in the Arduino compatible realm then it might be best to use the Bittle with the NyBoard. • If you already have some C++ Arduino coding experience and you want to move to the wider world of C++ with the ESP32, the Bittle with BiBoard is where it's at. Hope this helps! References: 1.       https://en.wikipedia.org/wiki/ATmega328 2.       https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32d_esp32-wroom-32u_datasheet_en.pdf 3.       https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32c3/hw-reference/chip-series-comparison.html 4.       https://www.petoi.com/blogs/blog/petoi-robotics-c-python-curriculums-coming-in-aug

I have found that the online instructions for the Petoi robots are VERY comprehensive (that's great!) but they can be hard to follow mainly because they are not very linear due to cross links among many web pages. When I recently upgraded my Bittle from having a NyBoard to having a BiBoard with Hat Extension, I took some notes that tried to "linearize" the online instructions. In the hopes that those notes may help others, I have attached the file, titled "My Bittle BiBoard Software Setup Instructions by este este v1.1.pdf". Let me know if you find it useful!

I like the small beep at the end of bootup in OpenCat32 but I am growing very tired of hearing the melody that plays at the beginning of bootup. How can I silence (but not delete) that boot up melody?

The IMU (inertial measurement unit) allows a robot to orient in its environment by perceiving YPR, i.e. Yaw, Pitch and Roll rotations, typically along the robot's z, y, and x axes, respectively. The IMU also allows perception of acceleration in the framework of the IMU itself (Real x, y and z directions) or in the framework on the robot's environment (World x, y, and z directions). Depending on the robot, the main uses of the IMU are for navigation (get/maintain robot movement heading using Yaw) and balancing (feedback/correction using Pitch and Roll). For most wheeled robots, stability is not a factor so the IMU is used for navigation. However, for legged robots like the Nybble and Bittle quadrapeds, stability can be a concern so the IMU can be used for balancing but navigation with the IMU can also be important. I mention this because I recently did a code review of OpenCatEsp32 and discovered that the current code uses one bool variable, gyroBalanceQ, as both the on/off switch for reading of IMU data for any purpose and the on/off switch for using such IMU data to balance the robot. I like the balance capability but sometimes I want to turn it off but not lose access to the IMU data for navigation. I therefore made some code changes in my forked repo of OpenCatEsp32. First I added a new bool variable in the global variables section of OpenCat.h, just under bool gyroBalanceQ: bool imuDataReadQ = true; Next, I modified readEnvironment() in io.h: if (gyroBalanceQ && !(frame % imuSkip)) was changed to... if (imuDataReadQ && !(frame % imuSkip)) And that is it! As long as imuDataReadQ is true, you will have IMU data, regardless of balancing being on or off. One could also add some more code to change imuDataReadQ programatically but that doesn't fit my current use cases. Since I believe this is generally useful, I will do a pull request from my fork into the Petoi OpenCatEsp32 repo for consideration. In the meantime, you can make changes to your own code in this way if you want this capability now. P.S. The same is true for the OpenCat repo except readEnvironment() is in imu.h. I am not using that repo so I will leave such changes there for others to make. P.P.S. I had not previously seen the use of a "Q" suffix in a bool variable name to indicate interrogative code reading syntax (as in a Question mark). I am more of an "isSometingTrue" code reading syntax person but I rather like the use of "Q" in that way! Edit: I change the bool name from ImuDataReadQ to imuDataReadQ to conform to the preference for camelCase in OpenCat32 rather than PascalCase (though, being a public variable, an argument could be made for PascalCase which is commonly used for public method and property names - not the same, I know but the same concept! 😀 )