top of page

Forum Posts

Timothy McCarthy
May 16, 2024
In Clinic
The purpose of the test is to measure the amount of current drawn by the P1L servo. For current measurement background see How to Measure Current with a Multimeter (youtube.com) Equipment •          • Multimeter • 1 P1L servo • 2 breadboards (830 tie points each) • 1 BittleX battery • ESP32S microcontroller • BittleX BiBoard, separated (not shown) • ESP32 USB cable • USB BittleX cable • 3 male-male black wires • 3 male-male red wires • 1 male-male green wire • 1 pair male - female dupont connector wires (not shown)      Connect the ESP32 ground pin with a black jumper wire to the top power rail ground rat ow 4. Connect the battery black ground wire to the top power rail ground at row 61, Connect the battery red power wire to the top power rail positive at row 61, Add jumper wires to the P1L servo connector, matching the black and red wires, and using the green wire for the signal. This is the same connection used in the Servo Test post.          Connect a red jumper wire from the top power rail at row 50 to row 50, a Connect the black servo ground wire to the top power rail ground at row 50 Connect the red servo power wire to the top breadboard at row 40, a. (Not the power rail.) Connect the ESP32 GPIO pin 33 to row 35,a Connect the servo signal wire to row 35,d This produces a "open circuit" similar to that of the servo test but with a open connection between the servo power and the positive battery. This is where we will be make the servo current measurement. Turn the batter on and connect the ESP32 with the USB cable. Verify that the battery light is on and the ESP32 power light is on. The servo should not move.      We make the current measurement by "closing the circuit" between the servo power and the battery power with the multimeter probes. When the circuit is closed, the servo moves. The video demonstrates the measurement. Link: https://youtu.be/taWsxyK686c The current fluctuates between 100 and 130 mA. This provides a reference for the servo current when powered. The final video replaces the ESP32 with the BiBoard to provide the servo signal (but not the servo power.) I made a simple jig to mount the BiBoard on two wooden sticks and used a pair of wires with dupont connectors from the BiBoard ground and signal pins to the ground rail and servo signal at 35, a, replacing the ESP32 signal wire there. The purpose of this step is not measure current but to verify that the USB only powered BiBoard sends a valid signal to the servo during the bootup sequence. I would not be able to measure the current due to the short time between powering the BiBoard and servo signal end. I would need a more complex circuit to perform that measurement. Link: https://youtu.be/5V0Bayp_AjI Results The servo current ranges between ~(100 - 130) mA. There are 9 servos in the bot so the total current is ~900 - 1170) mA. This does not include the "leak" current for the signal (per servo), the current for the BiBoard itself, or the current to the BiBoard hat. The head servo isn't as active as the others, so it can reduce the overall demand. Even so, that demand is north of 1A
Testbench: Servo current measurement content media
2
0
5
Timothy McCarthy
May 14, 2024
In Clinic
The purpose of the test is to verify the proper operation of a P1L servo. We'll use the common SG90 servo as a reference. Equipment • • 1 P1L servo • 1 SG90 servo • 2 breadboards (830 tie points each) • One 3.3-5v Power Supply Module with power cable • 1 BittleX battery • ESP32S microcontroller • ESP32 USB cable • 5 male-male black wires • 3 male-male red wires • 4 male-male green wires We will control the circuit with an ESP32 sketch that will have both servos "sweep" through positions between 0 and 180. This allows us to compare the P1L behavior with the SG90. It is worth noting that the circuit uses 3 separate power supplies, USB for the ESP32, 3.3-5v module for the SG90 servo, and tje BittleX Battery for the P1L servo. The voltage requirements of each of tthese devices is different from the others. The ESP32 uses a 3.3 volt, the SG90 uses 4.8 v, and the P1L uses 8v.          First, we add the ESP32 module to the breadboard 1 (on the top). The module is inserted into row 1, columns b and i. This provides a single column of ties on either side of the module (columns a and j) that simplfies locating the GPIO pins. We add the 3.3-5v power supply to breadboard 2, inserting it on the power rails on the right side, taking the first 5 rows. To provide a common ground for the circuit we connect the ground rails of the top power rail of each breadboard and add a jumper wire from the ESP32 GND pin to the ground rail of the bottom board      For the SG90 servo connections add a red wire to the power (red) connector, a black wire to the ground (brown) connector, and a green wire to the signal (yellow) connector. Connect the SG90 power and ground jumper wires to the second breadboard top power rail at row 25. This rail is connected to the 5v output of the power supply. Connect the SG90 signal jumper wire to row 25, a. This completes the circuit for the SG90 servo. For the P1L servo, repeat the steps to add jumper wires for power, ground, and signal to the P1L connector. Connect the P1L power and ground jumper wires to the top breadboard, top power and ground rail at row 35. Connect the P1L signal jumper wire to the top breadboard at row 35, a For the battery, add red and black wires to the power (red) and ground (black) connectors For the SG90 signal, use GPIO pin 32, located at row 13, i. Add a jumper wire that to the top breadboard at row 25,c. This connects the GPIO pin to the SG90 signal wire. For the P1L signal, use GPIO pin 33 located at row 12, i. Add a jumper wire that to the bottom breadboard at row 25,d. This connects the GPIO pin to the P1L signal wire. Connect the power lines by connecting the USG to the ESP32, the power cable to the 3.3-5 power module, and the battery to the top power rail red wire to the positive and black wire to the negative rails. The battery connection is not shown in the picture. The ESP32 sweep sketch to control the servos is an adaptation of a common sketch that "sweeps" the servo back and forth through 180 degrees. /* Adapted from .. Sweep by BARRAGAN This example code is in the public domain. modified 8 Nov 2013 by Scott Fitzgerald modified for the ESP32 on March 2017 by John Bennett see http://www.arduino.cc/en/Tutorial/Sweep for a description of the original code * Different servos require different pulse widths to vary servo angle, but the range is * an approximately 500-2500 microsecond pulse every 20ms (50Hz). In general, hobbyist servos * sweep 180 degrees, so the lowest number in the published range for a particular servo * represents an angle of 0 degrees, the middle of the range represents 90 degrees, and the top * of the range represents 180 degrees. So for example, if the range is 1000us to 2000us, * 1000us would equal an angle of 0, 1500us would equal 90 degrees, and 2000us would equal 1800 * degrees. * * Circuit: (using an ESP32 Thing from Sparkfun) * Servo motors have three wires: power, ground, and signal. The power wire is typically red, * the ground wire is typically black or brown, and the signal wire is typically yellow, * orange or white. Since the ESP32 can supply limited current at only 3.3V, and servos draw * considerable power, we will connect servo power to the VBat pin of the ESP32 (located * near the USB connector). THIS IS ONLY APPROPRIATE FOR SMALL SERVOS. * * We could also connect servo power to a separate external * power source (as long as we connect all of the grounds (ESP32, servo, and external power). * In this example, we just connect ESP32 ground to servo ground. The servo signal pins * connect to any available GPIO pins on the ESP32 (in this example, we use pin 18. * * In this example, we assume a Tower Pro MG995 large servo connected to an external power source. * The published min and max for this servo is 1000 and 2000, respectively, so the defaults are fine. * These values actually drive the servos a little past 0 and 180, so * if you are particular, adjust the min and max values to match your needs. */ #include "ESP32Servo.h" namespace esp32 { namespace example { namespace sweep { // create servo object to control a servo // 16 servo objects can be created on the ESP32 Servo SG90; Servo P1L; int pos{ 0 }; // variable to store the servo position // Recommended PWM GPIO pins on the ESP32 include // 2,4,12-19,21-23,25-27,32-33 int SG90_servoPin{ 32 }; int P1L_servoPin{ 33 }; void on_setup() { Serial.begin(115200); // Allow allocation of all timers ESP32PWM::allocateTimer(0); ESP32PWM::allocateTimer(1); ESP32PWM::allocateTimer(2); ESP32PWM::allocateTimer(3); SG90.setPeriodHertz(50); // standard 50 hz servo P1L.setPeriodHertz(50); // standard 50 hz servo // attaches the servo on pin SG90_servoPin to the servo object // using default min/max of 1000us and 2000us // different servos may require different min/max settings // for an accurate 0 to 180 sweep SG90.attach(SG90_servoPin, 500, 2400); P1L.attach(P1L_servoPin, 500, 2500); SG90.write(0); P1L.write(0); } void on_loop() { Serial.print("Forward\n"); // goes from 0 degrees to 180 degrees // in steps of 1 degree for (pos = 0; pos <= 180; pos += 1) { // tell servo to go to position in variable 'pos' SG90.write(pos); P1L.write(pos); delay(15); // waits 15ms for the servo to reach the position } Serial.print("Backward\n"); // goes from 180 degrees to 0 degrees for (pos = 180; pos >= 0; pos -= 1) { SG90.write(pos); P1L.write(pos); delay(15); } } } // namespace sweep } // namespace example } // namespace esp32 using namespace esp32::example::sweep; void setup() { on_setup(); } void loop() { on_loop(); }          This produces the output: Sketch uses 272949 bytes (20%) of program storage space. Maximum is 1310720 bytes. Global variables use 21716 bytes (6%) of dynamic memory, leaving 305964 bytes for local variables. Maximum is 327680 bytes.      If all goes well, then turn the power supply on with the button on the module and the SG90 servo should start to rotate. Turn the battery on by pressing the button and the P1L servo should start rotating. Test Result          Here's the video of the circuit in action. https://youtube.com/shorts/aSo24Ph85Go?feature=share The test verification is visual. You should see the servos move, with the SG90 sweeping through ~180 degrees and the P1L servo sweep ~250 degrees. There's a problem with the P1L servo if it doesn't move, or moves in a erratic or jerky manner. To test additional P1L servos, simply swap the servo out via its jumper wires. Question: I know that the P1L servo has a large angle of rotation (like 240-270) but clearly the position of the SG90 and the P1L for the same angle don't agree. My question is, "How do I know where the P1L actually servo is when I tell it to move to a n angle?" What's the transform between 180 degree and P1L position?
Testbench: Servo testing content media
1
0
6
Timothy McCarthy
May 11, 2024
In Clinic
The purpose of the test is to verify that the BittleX battery is providing the correct voltage to power the BittleX robot. Equipment: BittleX battery with USB connector Multi-meter with probes breadboard 2 male-male 18 or 22 guage wires, one red, one black Recharge the battery      Make sure the battery is fully charged Connect the battery to a USB power connection. The battery light should come on. When the light turns green the battery is fully charged. Disconnect the USB cable from the battery Connect the battery to the breadboard Turn the battery off by pressing the battery button until the light is off Insert one end of the red wire into the battery connector connected to the red wire of the battery. Insert the other end of the red into the breadboard positive rail colored red and marked '+'. Insert one end of the black wire into the battery connector connected to the black wire of the battery. Insert the other end of the black wire into the breadboard ground rail colored blue (or black) and marked '-'. Follow the user manual for the multimetter to connect the probes to the multimeter. Remove any protective cover to the probe ends. Turn the multimeter on and follow the user manual to set to measure DC voltage. Press the battery button so the blue light is on. Insert the Probe for ground (should be black color) into one of the breadboard ground rail holes of the rail that has the battery black wire. Insert the Probe for positive voltage (should be red color) into one of the breadboard positive rail holes of the rail that has the battery red wire. Read the voltage from the meter. Here it's 8.29 v If everything goes well, the meter should read about 8.3 volts. Common electronics voltages are 3.3 and 5 volts. So 8.3v doesn't seem to be a coincidence. Turn the battery off by pressing the battery button until the light is off
BittleX Battery Voltage Test content media
1
0
20
Timothy McCarthy
May 02, 2024
In Clinic
This started out of the blue. bootfail.mp4 It looks like he got into the liquor cabinet. The only additional symptoms I have are: 1. I had just completed a run of unit tests with a failure for SKILL_DATA. The write of the data failed trying to write 934 byte and only writing 704 bytes. So, there may have been a buffer overrun issue. 2. The voice command has been dropping out for some reason. A stray sound (like a cough) can turn it back on. But then it drops out again. The battery was just recharged. Tell me doc, will he make it? What's the matter?
Time to see the Vet content media
0
66
210
Timothy McCarthy
Apr 21, 2024
In Hardware
I'm looking for some guidance on how to tidy up the cables on the arms and legs. The problem is that they keep poking out after any activity. I keep trying to tuck them into the sleeve guards, but they work their way out very quickly. When put on my test stand, the wires keep banging against the column, which is annoying, but the real concern is they will get caught up something and befoul movement. Any tips would be greatly appreciated.
Cable Management guidance needed content media
0
7
31
Timothy McCarthy
Apr 20, 2024
In Software
(aside: I think something went south on the first attempt of this post so this may be a duplicate) I'm writing unit/feature tests of the serial protocol API and I'm working on the analog read command (Ra<pin>). The pin I use (VOLTAGE, pin 4) comes from the lowBattery function in reaction.h and is defined in opencat.h. The test is performed on a fully changed battery. I'm having difficulty understanding the response: = 383 R I expected to get a value between 0 - 4096 but at the high end of the range. The lowBattery code reads the value into a float bool lowBattery() { //... float voltage = analogRead(VOLTAGE); and compares the value with a precalculated low_voltage value: //... float vFactor = 4096 / 3.3 / 3; float low_voltage = LOW_VOLTAGE * vFactor; //... if (voltage == 0 || voltage < low_voltage ...) The value of vFactor should be 413.73..., and thus the value of low_voltage is 2813.41... This doesn't look right. So, I'm missing something here. Is the command response (383) valid? I expect it to be an integer. I don't understand the calculation in lowBattery. :
0
3
28
Timothy McCarthy
Apr 20, 2024
In Software
I'm writing unit/feature tests of the serial protocol API and I'm working on the digital read command (Rd<pin>). The pin  I  use (VOLTAGE, pin 4) comes from the lowBattery function in reaction.h and is defined in opencat.h. The test is performed on a fully charged battery. I'm having difficulty understanding the response: = 383 R             I expected to get a value between 0 - 4096 but at the high end of the range. The lowBattery code reads the valiue into a float. bool lowBattery() { //... float voltage = analogRead(VOLTAGE); and compares the value with a precalculated low_voltage value: #define LOW_VOLTAGE 6.8 //... float vFactor = 4096 / 3.3 / 3; float low_voltage = LOW_VOLTAGE * vFactor; //... if (voltage == 0 || voltage < low_voltage ...) The value of vFactor should be 413.73..., and thus the value of low_voltage is 2813.41... This doesn't look right. I'm missing something here. Is the command response (383) valid? I expect it to be an integer. I don't understand the calculation in lowBattery.
0
0
11
Timothy McCarthy
Apr 19, 2024
In Software
I misstated the command. I'm testing the analog command Ra<pin>
0
0
13
Timothy McCarthy
Feb 17, 2024
In Basic Assembly and Setup
Disclaimer The ideas expressed here are my subjective opinions based upon 40 years of software development. I've spent a considerable amount of time documenting or explaining software to people with a wide range of experience with a equally wide range of success. Documenting technical information, either hardware or software, is a difficult task and more often evolves over time. I don't have clear guidelines but do have a few principles that have been helpful, and I know what feels wrong or right when I find it. In any event, these are my opinions and yours may vary. No offense taken or given. Petoi Doc Center and the Bittle X Assembly My experience with the Petoi Doc Center and the assembly process for the Bittle X robot is the focus my comments here. The Petoi Doc Center has lots of links and documents on a wide range of topics. This is both an advantage and a disadvantage. The advantage is the range of information available to the user, The disadvantage is that all that information needs organization and maintenance. For the majority of the Doc Center cross links can significantly reduce the organization and maintenance. Users won't be distracted by following the links to different pages ... except when following installation or assembly instructions. Then they want straight line, sequential steps with no deviations. Don't refer them to another page (that saved you maintenance effort. Remember, you're saving their time, not yours.) Whenever possible, verification steps should be used for positive feedback. Background information or justification should be avoided until after the final step. After things are working they'll appreciate the why and if things aren't working the explainations won't be all that helpful. Keep the target user in focus. For assembly instruction it's the least experienced user. More  experienced users will skim over the basics with little effort. Less expereinced users will be easily confused. Identify things early and be consistent. Is it a sholder or hip? Leg or arm? Or just joint1, joint2, etc. Honestly, the joint numbers still doesn't make sense to me. In my opinion they should be numbered so that I can tell you which is which off the top of my head. There are only 8 servos. Zero is the head and the rest follow sequentially, left sholder-arrm, right sholder-arm, left hip-leg, right hip-leg. I can identify which one given the number or the description in my head. I think the average 12 year old could as well. There  are  only 8 servos but there are joint numbers 9-15 that hop around the body. This kind of complex numbering should come after initial assembly. So, as a concrete example, let me describe some of my thoughts on the Bittle X assembly and go into some detail on the calibration instructions. That package contains a parts list and I do go through these lists and locate all the parts. I was successful but there was an extra part. There's a spare servo but there's also a tiny nylon servo reduction gear that's not on the packing list. (I hope we aren't expecting to open a servo and replace a reduction gear.) The instructions in the package give me the QR code that brings me to the Doc Center website that I've nver been to before. I'm looking for assembly instructions for a Bittle. (At this point I'm not aware of the distinction between a Bittle and a Bittle X.) The page has the Getting Started link and that links to the Bittle page. I quickly get past sections 1 and 2 with no cause for alarm. Principle: the product should have a clear means of identification and the user instructed to find it. As it turns out, if I had followed the Bittle X link I would have ended up on Step 3 which tells me: "The assembly process of Bittle X is the same as Bittle except for the wire connection on BiBoard." This has a link to the Bittle assembly section 3 because they are the same, right? But as soon as I go the page I realize they aren't. The heading on the page says, "3.1 Start with the Unassembled Kit" but my Bittle X is partially assembled. I now must read through sections 3.1, 3.2, 3.2.1, 3.2.2, 3.2.3 and stop at section 3.2.4 and forget everyting I just read. Everything went fine up until section "3.2.7 Battery" where this note appears: The controller board is already fixed on the body in the following picture. You can finish the Connect Wires chapter and then return here. This is what I think is a major flaw in presentaions, instructions, and documentaion. This skips a step and tells you to read the instructions out-of-order then return here. But it gets worse. We were told when we came here that the only difference between Bittle and Bittle X was the wiring. What we wonder is where are the wiring instruction for Bittle X? What we don't know until we read past the NyBoard wiring, which doesn't look anything like our board, is the the BiBoard wiring is shown. But then the pictures revert back to the NyBoard! Those photos show the wire wrapped around the board support posts, which is physically impossible for the BiBoard with the hat. Nor have we been shown how to install the board (is the hat up or down?) I won't go further here into my experience with the wiring other than to say it was extremely cramped and fraught with peril. It was as a result of this that I desperately wanted to verify that the wiring was electrically sound before I went any further. After tearing down and reassembling the robot 5 or 6 times I found a way to do it easily and reliably. You first need to know that the hat faces down, not up. You might deduce that from the photo of the Bittle X wiring. But it should be pointed out. Second, and most important, don't screw the board to the frame until after you connect the servo wires. You have more slack in the wires and more room to connect them to the proper pins. Third, the target user doesn't know positive or negative or ground or color coding. They do know black from white though. A simple guide, "Black on top, pin closest to the main board with the big silver square" leads  to the second guide: the pins are numbered and should be used. Left front arm goes to 32, left sholder goes to 33, head goes to 19. Isn't this the reason the numbers are on the board? OK, this is long enough  on  this. Once more, these are my opinions and I'm retired and probably a little out of step. Next post I'll try to tackle the calibration process.
1
2
45
Timothy McCarthy
Feb 15, 2024
In Basic Assembly and Setup
My Bittle X is misbehaving. I purchased the STEM version and followed and completed the assembly process but I'm not certain it's correct. Running the UI program to calibrate the joints I get unexpected results when selecting the different postures. All the joints are zeroed. Using the IR remote I get similar misbehavior. The Arduino IDE can successfully connect the console to the BiBoard and get output. I have not uploaded any sketch to the ESP32 nor updated the firmware so the software is as shipped. I'm reluctant to upload a sketch or firmware until I know the cause of the misbehavior. I'm not familiar with the ESP32 archetecture (yet) so I don't know if uploading a sketch will erease the misbehaving code. I have not compiled the OpenCat software yet. Misbehavior Description 1. Uncertain Calibration posture 2. Incorrect Stand posture 3. Intermittent Voice Command 4. Head-Arm clearance 5. Remote Control layout At this point I need assitance to get past these issues; I've run out of ideas for non-destructive tests and afraid of making unrecoverable changes. I suspect the problem is due to a simple assembly or software error. I won't describe each problem in this post but will in subsequent posts as I become more familiar with using this forum. But to start I will post the output from the UI and Aduino consoles and (hopefully) a picture of the incorrect stand posture to provide a starting point for discussion. Some questionss: "Is Bittle X properly assembled?" Rest posture Note: The sholder servos have the logo facing inward. The leg servos have the logo facing outward. As far as I can  tell the leg and arm connectors are identical; I followed the videos and put the red sholder on the top-outside of all 4 legs. "Is this the correct calibration posture?" Calibration Posture I'm not sure what the purpose of the Calibration pose is. The UI uses it when adjusting the servo offsets but the Rest pose is the one used for the initial calibration. Adjusting from the calibration pose has no reference. The back legs tend to collide with the body frame with disturbing sounds. This is the incorrect stand posture Stand Posture UI Console output ardSerial date: Jan 23, 2024 ['3', '7', '9'] C:\Users\...\.config\Petoi already exists C:\Users\...\.config\Petoi\defaultConfig.txt 2024-02-12 23:50:16,911 ardSerial - INFO - ['English', 'Bittle X', '.\\release', '2.0', 'NyBoard_V1_2', 'Standard', 'Nature', 'Earth'] *** Available serial ports: *** COM5 Bittle B_231106 2024-02-12 23:50:30,859 ardSerial - INFO - Connect to serial port list: 2024-02-12 23:50:30,859 ardSerial - INFO - COM5 re ['c\r\n', 'calib\r\n0\t1\t2\t3\t4\t5\t6\t7\t8\t9\t10\t11\t12\t13\t14\t15\t\r\n0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t0,\t\r\nc0,\t0,\t\r\n'] of calib 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, c0, 0, Arduino IDE Console output (Battery OFF) Scanning I2C network... - I2C device found at address 0x54 ! - I2C device found at address 0x5C ! - I2C device found at address 0x68 ! - I2C device found at address 0x69 ! - I2C device found at address 0x7E ! - done Initializing MPU... OK - Testing MPU connections...attempt 0 - MPU6050 connection successful - Initializing DMP... - Enabling DMP... - Enabling interrupt detection (Arduino external interrupt 26)... - DMP ready! Waiting for the first interrupt... Bluetooth name: Bittle0E Waiting for a client connection to notify... Bluetooth name: Bittle0E The device is started, now you can pair it with bluetooth! Setup ESP32 PWM servo driver... Calibrated Zero Position 135 120 135 135 190 80 190 80 190 80 80 190 Build skill list...60 Init voice Number of customized voice commands on the main board: 10 TaskQ Ready! rest g d Thanks
Bittle X Assembly and Calibration Misbehavior content media
0
10
61
Timothy McCarthy
Feb 15, 2024
In Software
Does anyone have a working Arduino build for Bittle X ESP32 they can share? I'm struggling to follow the documentation but it's left me uncertain if I have a proper build process. I have a STEM Bittle X ESP32 but it's misbehaving at the calibration step. I'm resonably certain of the body and electrical assembly are correct; I can use the Arduino console to control all the servos and they seem to display a full 180 degree range (-90 to 90); the Rest and Calibration poses appear to be correct. The Stand pose is invalid; the rest of the poses are "close" but still invalid. Most of the behaviors are unstable and some are spasmotic. The voice command has worked only once and stopped. The IR works but some buttons are inactive. Before I overwrite the shipped softwrae I want to be sure I have a correct build so I don't "brick" the robot. I'd also like to diagnose what's wrong with the shipped code. I have a Windows 11 with Arduino 2.3.1. This is working; I have an Elegoo Arduino that I can write sketches to. I've installed the ESP32 library from Expressif (v2.0.12) but found nothing on how it is used in the OpenCat.ino build.. I was able to successfully compile the OpenCat build for an Arduino UNO when disconnected from robot. It uses 99% of the program space and nearly all the dynamic memory. That doesn't use all ESP32 memory. I didn't find any documentation on how to setup the BiBoard and only by chance, after searching all over the site, I found OpenCat32. I successfuly compiled (with a few changes due to compile errors) that with the ESP32 Dev Module: "Sketch uses 1207073 bytes (92%) of program storage space. Maximum is 1310720 bytes. Global variables use 43640 bytes (13%) of dynamic memory, leaving 284040 bytes for local variables. Maximum is 327680 bytes." These results are disappointing. I'm just not sure I have this right. Questions: • Do I have to use Arduino 1.18 IDE? • Do I have to use 2.0.12 Expressif version? • How to setup a BiBoard or is ESP32 Dev Module the right board? Thanks
0
1
34

Timothy McCarthy

更多動作
bottom of page