@Rongzhong Li You are doing fantastic work with Biddle. You have your priorities correct.

I also was inspired by the transform() function, and like Len, replaced it with a linear interpolation for its simplicity and speed. My focus has been on software rather than hardware. My Nybble can now walk at 5 complete cycles per second, but loses contact with the floor at 2-3 cycles per sec. I.E. it slips. I suspect I need adaptive feedback. Sensors on the feet and software to adapt the motion are probably needed. As for stringing motions together, I always remember the last position of each joint . Since I also use the Translate() - like motion, when a new instinct is invoked,, the software linearly interpolates from whatever the previous angle was, to the first angle of the new instinct. For me, there are typically 4 to 50 interpolated steps between each line of the instinct. (Walk has 42 lines, for example). So, it can be quite smooth.

@Rongzhong Li , Will your translations be for Biddle, Nybble or both? I have created some software to translate 2D foot positions to Nybble leg angles. I have found it to speed up creation of new Instincts. You may already have developed better tools for Biddle/Nybble. 3D is obviously more complex! My software is on Visual Studio, but could easily be changed to a simple command line C program if someone found it useful. If there is code out there that you use, I am interested! leg angles Code: https://github.com/MarkDeNies/Nybble-Walk/tree/main/LegAngles (this is an MFC dialog box program, which is crude. A quick/dirty program. If you wish to use it, you will save yourself a lot of time if you ask me how to use it -- It is only obvious to me!!

Good job!! I see you are using the "trot" gait. I've been working with the Walk gait, and am still trying to eliminate the slipping when feet moving up and forward touch the ground too soon, and push Nybble back. I haven't been brave enough to try to prevent this on the Trot gait (which requires balancing on two feet, at least for the moment!). It looks like you have boots on each foot for better traction, a good idea!, but I've discovered that if the foot hits the ground while it is going forward, it still pushes Nybble backwards. Better gripping works both ways. Do you have any improvements/insights since your last post? I have a related post under "variable speed walking" for comparison.

I also had this problem when one of the wires from the battery to the green power in block on the circuit board was loose. It looked OK, but the screw wasn't tight.

The sound is due to battery low. Either the throw switch on the battery holder is open, or you need new, freshly charged batteries.

Hi. I've had similar problems in the past. I have two suggestions to help narrow in on the problem. First: be careful not to overuse the print function. Too much data going to the Serial line can interfere with other devices, such as the MPU6050. Also, you can try commenting out the #define GYRO in OpenCat.h. This will disable the MPU code, and thus the "adjustments" that will be sent to balance Nybble. It's possible that there is something intermittent going on with the MPU board, or more likely, the adjustment code (perhaps a timing issue). Hope that helps.

After testing the kalman filter, I found one error and better values for Q and R. The error caused it to always return a zero adjustment. The corrected code and constants are: // Kalman filter. x is the state, p is the error (covariance). z is the most recent measurement. // Constants which affect it's behavior: q (transition error): large values make it track the // measurement values, r (measurement error): small values cause it to track the measurement values. float prevKalman[16]= {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; float prevError[16]={1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0}; #define Q .01 // works for me. You may need to vary it a bit #define R .4 // A good value for my Nybble void kalman(float &xPrev, float &pPrev, float z) { float x = xPrev; float p = pPrev + Q; // update float y = z - x; // difference between measurement and prediction float kg = p * 1.0 / (p + R) ; // Kalman Gain xPrev = x + kg * y; pPrev = (1 - kg) * p; }

I had noticed a similar problem when I got Nybble back in August. Too bad I hadn't learned to check these posts. It took a few days to come up with a very similar fix...

Thanks Rongzhong! To change speed, I did several things: First, less frequent calls to checkBodyMotion (more below), then, when the loop is run, I update the motors only when the current time is greater than 40ms since the last time. I then update ALL the motors. Taking a cue from your transform() function, I linearly interpolate between duty points (entries in the instincts). By changing the number of interpolation steps, I change the speed. From 1 step (fastest) to 50 steps (very slow). Since the motors are all updated at once, this gives a significant speedup all by itself. I use two buttons on the remote to increase or decrease "stepsPerDuty". The code: if(bRunning) { if (tPrevMotorCall + tMotorWait <= tCur) { checkBodyMotion(); //fetch current gyro info only when needed tPrevMotorCall += tMotorWait; // tMotorWait is typically ~40ms for (int i=0; i<8; i++) { int dutyIdx = iDuty * WALKING_DOF + jointIdx - firstMotionJoint; float prevAngle = previousAngle[i]; float targetAngle = motion.dutyAngles[dutyIdx]; float stepAngle = iStep * float(targetAngle-prevAngle)/stepsPerDuty; float adj = adjust(jointIdx); mostRecentAngle[i] = prevAngle+stepAngle; //save most recent angle for this motor (used below) calibratedPWM(jointIdx, prevAngle + stepAngle + adj); jointIdx++; } jointIdx = DOF - WALKING_DOF; iStep++; if (iStep > stepsPerDuty) { //when finished the last interpolation, advance to the for (int i=0; i<8; i++) // next Duty step (entry in the current skill) previousAngle[i] = mostRecentAngle[i]; iDuty++; iStep = 1; if (iDuty == motion.period) iDuty = 0; bFirstLoop = false; // bFirstLoop is used for debugging only } } } Some explanation is probably needed: prevAngle[] contains the previous duty angle (from the intrinsic tables) for use in interpolation. UNLESS a new motion was started --in which case it will contain the most recent interpolated angle. This allows the new motion to smoothly interpolate from wherever Nybble was in the previous skill to the first position of the current skill. Also, checkBodyMotion() is only called when I need a adjustment value, since it takes significant time. But this causes trouble with its queue overflowing. So I found some fairly simple code to read the IMU registers directly and calculate the angles. Since this replaced the Rowling IMU library, it also saved 6K of program space and speeds up everything.