Only You, or ESP8266 Forever!

[KomX]

Hi, Shivakumar.

Quote:used 1/8 micro stepping.
(1/16 micro stepping is not working for me.. Motor buzzing and no movement if loaded)

The latest revisions of the frequent references to skip steps when starting motors I added zeroing variable PID_errorSum in this section of code eX_ESP_Robot.ino:

Code:

else   // Robot not ready (flat), angle > 70º => ROBOT OFF
    {
      PIN_HIGH(MOTORS_ENABLE_PIN);    // драйвера не активны
      PID_errorSum = 0;  // Reset PID I term
      control_output = 0;
      Kp = KP_RAISEUP;   // CONTROL GAINS FOR RAISE UP
      Kd = KD_RAISEUP;
      Kp_thr = KP_THROTTLE_RAISEUP;
      Ki_thr = KI_THROTTLE_RAISEUP;

      // if we pulse push1 button we raise up the robot with the servo arm
      if (push[0])
      {
        // Because we know the robot orientation (face down of face up), we move the servo in the appropiate direction for raise up
        if (angle_adjusted>0)
          te_SetServo(SERVO_MIN_PULSEWIDTH);
        else
          te_SetServo(SERVO_MAX_PULSEWIDTH);
      }
      else
        te_SetServo(SERVO_AUX_NEUTRO);

}

Can it comment out to restore the original reaction of the robot during its ascent ...

I can not give more detailed advice, so do not have information about the operating conditions of your motors.

Quote:Used GPIO16 for Xstep ( moved the sonar pins to 9 and 10 but not used)

Some modification to suit for CNC shield
/// X motor Step pin ///
#define PIN_LOW1(x) (GP16O &= ~1)
#define PIN_HIGH1(x) (GP16O |= 1)

PIN_LOW1(MOTOR1_STEP_PIN);

Replacement pins for alternative hard for me to comment because the choice of a pin, I shall be guided by the ESP capabilities and insufficiently documented its operating logic.
In particular, GPIO16 was put on the gate of the ultrasonic range finder due to the fact that the latter is not so important in the normal operation of the robot (many do not use it at all), and due to the fact that the module firmware uses for its work GPIO2 and GPIO16.

Quote:I think there is an error in eX_ESP_OSC.h

///////////////////////////////
if (PacketBuffer[3]=='f') // команда FADER
{
fadder[int(PacketBuffer[8] - 49)] = OSC_Extract_Param(PacketSize);
///////////////////////////////

it suppose to be....
fadder[int(PacketBuffer[8] - 48)] = OSC_Extract_Param(PacketSize);
---
Now the App is working .....

The resulting variables fadder[x] are stored in the four-dimensional arrays with indices 0 ... 3.
Because the OSC receives command "fader1", "fader2", "fader3" and "fader4" (On the one letter "d"!)
Therefore, to obtain the correct index is subtracted 49. You're subtracting 48, receive the wrong code and error execute commands on the second page of the control, where all four controls are used.
The error is not likely in the sketch and in the incorrect recording of names of commands used in your layout file.

Quote:When no movement stand still only for about 20s to 30s... then all of a sudden losing balance and it is falling down.
when controlling with app occasionally..it is going out of balance...and it is falling down.
Left * right rotation is rock soilid but front and back is not very stable.. sudden change of direction makes it to falldown.
sometimes it seems to be error and stop balancing and falling down..

Basically everywhere sketch (eX_ESP_Robot.ino) is processed fadder[0] as throttle and fadder[1] as steering. What happens to you after you replace 49 to 48 I do not presume to analyze.

Sincerely, KomX.
Forgive inadequate machine translation.