Xe robot mài nền

chưa lắp cảm biến và bánh xe, khi bấm auto thì thời gian chưa đếm lùi

Đúng. Trường hợp này khả năng cao AUTO thực tế chưa được ESP32 chấp nhận, vì code hiện tại chỉ startAuto() khi bnoReady == true. Bạn chưa lắp BNO086 nên nhấn AUTO bị trả về "BNO086 chưa sẵn sàng", do đó autoStartMs chưa bắt đầu và đồng hồ vẫn --:--.

Tôi sẽ sửa logic để giai đoạn test chưa lắp cảm biến vẫn bấm AUTO và đồng hồ đếm lùi bình thường. Khi lắp cảm biến sau, ta bật lại điều kiện an toàn BNO/Hall.

đường kính bánh xe 16cm, 30 xung = 1 vòng, tính khoảng cách cho tôi theo cm

Với bánh xe đường kính 16 cm, 30 xung Hall = 1 vòng:

Chu vi bánh xe:

Vậy 1 xung tương ứng:

Công thức tính khoảng cách:

Ví dụ: 30 xung = 50.27 cm, 100 xung ≈ 167.55 cm, 2000 xung ≈ 3351 cm = 33.51 m.

------------------------------------------------

AUTO đang chạy theo kiểu ziczac/lawn-mower, với chu trình như sau.

BẤM AUTO
   ↓
Bật máy mài + máy hút
   ↓
TIẾN THẲNG
   ↓
BNO086 giữ hướng
   ↓
┌─────────────────────────────┐
│ Có vật cản trong khoảng     │
│ cảnh báo LiDAR              │
│           HOẶC              │
│ đạt Khoảng cách MAX         │
└──────────────┬──────────────┘
               ↓
             STOP
               ↓ 400 ms
        QUAY PHẢI 90°
               ↓
          TIẾN L1
               ↓
        QUAY PHẢI 90°
               ↓
          TIẾN THẲNG
               ↓
          gặp cuối đường
               ↓
        QUAY TRÁI 90°
               ↓
          TIẾN L2
               ↓
        QUAY TRÁI 90°
               ↓
          TIẾN THẲNG
               ↓
       lặp PHAI ↔ TRÁI

1. Khi bấm AUTO

startAuto() thực hiện:

autoMode = true;
autoState = AUTO_FORWARD;
autoTurnRight = true;

Sau đó lấy hướng hiện tại của BNO086 làm 0°, reset quãng đường, bật:

accessoriesOn();   // máy mài + máy hút

rồi gọi:

motorForward();
captureAutoHeading();

Nghĩa là lần đầu AUTO luôn bắt đầu bằng đi thẳng, và lần quay đầu tiên là bên phải.

2. Khi chạy thẳng

Ở trạng thái:

AUTO_FORWARD

AUTO liên tục kiểm tra hai điều kiện:

frontObstacle()

hoặc:

roadCm >= maxDistance

Chỉ cần một trong hai xảy ra → xe STOP và chuẩn bị quay.

LiDAR hiện kiểm tra cả 3 vùng TRÁI + GIỮA + PHẢI. Chỉ cần một vùng có vật ở khoảng cách nhỏ hơn:

warningDistance

là được coi là gặp vật cản.

3. BNO086 đang giữ hướng

Trong AUTO_FORWARD và AUTO_SHIFT, code gọi:

updateAutoHeadingHold();

khoảng 25 lần/giây.

Nó so sánh:

currentYawDeg

với:

autoHeadingTargetDeg

rồi tăng/giảm điện áp hai bánh:

leftV  = baseV - correction;
rightV = baseV + correction;

Thông số hiện tại:

HEADING_KP = 0.018
HEADING_DEADBAND = 0.8°
HEADING_MAX_CORR_V = 0.45V

Tức BNO086 đang thực sự tham gia chỉnh lệch trái/phải khi chạy thẳng.

4. Khi gặp cuối đường

AUTO STOP trước:

motorStop();

đợi:

400 ms

sau đó quay tại chỗ bằng BNO086.

Lần đầu:

Quay PHẢI → turnAngleRight

mặc định hiện tại là:

turnAngleRight = 90;

Nó không quay theo thời gian mà đo góc BNO:

fabs(angleDiff(...)) >= target

đủ 90° mới dừng.

5. Sau đó chạy L1

Sau lần quay phải thứ nhất:

→ chạy thẳng L1

Mặc định:

distanceL1 = 100 cm

Khoảng cách này được tính bằng Hall:

getShiftDistanceCm()

Khi đạt L1 → STOP → lại quay phải 90°.

Sau đó bắt đầu đường thẳng tiếp theo.

6. Cuối đường tiếp theo đổi sang trái

Sau khi hoàn thành một lượt phải, code:

autoTurnRight = !autoTurnRight;

nên lượt tiếp theo:

Quay TRÁI
→ đi L2
→ quay TRÁI
→ đi thẳng

Sau đó lại đổi thành phải.

Vì vậy đường đi là:

↑ ↑ ↑
│ │ │
│ └─┐
│   │
└─┐ │
  │ │

đúng kiểu quét ziczac mặt nền.

7. Thời gian AUTO

Code cũng kiểm tra:

maxWorkTime

mặc định hiện tại:

30 phút

Khi hết thời gian:

stopAuto();

→ dừng xe + tắt máy mài + máy hút.

Trong code hiện tại, nút AUTO bị khóa nếu BNO086 chưa sẵn sàng.

Trong handleMode() đang có:

if(mode=="auto"){
    if(!bnoReady){
      server.send(503,"text/plain; charset=utf-8","BNO086 chưa sẵn sàng");
      return;
    }
    startAuto();
    Serial.println("MODE = AUTO");
}else{

Vì bạn đã tháo/comment BNO nên:

bnoReady = false;

→ chương trình return ngay → startAuto() không chạy → máy mài/hút vẫn OFF → MODE vẫn MANU.

Sửa ngay chỗ này

Thay toàn bộ handleMode() bằng:

void handleMode()
{
  String mode = server.arg("mode");

  if(mode == "auto")
  {
    // TAM THOI KHONG KIEM TRA BNO086
    // if(!bnoReady){
    //   server.send(503,"text/plain; charset=utf-8","BNO086 chưa sẵn sàng");
    //   return;
    // }

    startAuto();
    Serial.println("MODE = AUTO");
  }
  else
  {
    stopAuto();
    Serial.println("MODE = MANU");
  }

  server.send(200,"text/plain","OK");
}

Sau sửa, bấm AUTO thì ít nhất Serial phải xuất hiện:

MAY MAI: ON
MAY HUT: ON
AUTO: FORWARD
MODE = AUTO

và web phải chuyển:

MODE = AUTO
MAY MAI: ON
MAY HUT: ON

Nhưng còn một vấn đề tiếp theo

Trong startAuto() vẫn có:

motorForward();
captureAutoHeading();

Tạm thời comment BNO:

motorForward();

// TAM TAT BNO086
// captureAutoHeading();

Serial.println("AUTO: FORWARD");

Và trong updateAuto() còn phần quay 90° dựa vào currentYawDeg. Nếu chỉ sửa handleMode() thì AUTO sẽ bắt đầu chạy được, nhưng đến cuối đường lúc cần quay 90° sẽ không hoạt động đúng vì không có BNO.

---------------------------------------------------

trong setup, Thêm 2 ô nhập đặt dưới Thời gian làm việc MAX, Khoảng cách di chuyển: 15cm và ô Thời gian dừng: 5 giây, Khi bấm auto thì xe tiến 15cm và dừng 5 giây, cứ lặp lại như vậy, các nội dung khác giữ nguyên

Với yêu cầu này, tôi khuyên không sửa cấu trúc AUTO hiện tại, chỉ thêm một cơ chế “tiến ngắt quãng” vào trạng thái chạy thẳng:

AUTO
→ tiến 15 cm
→ STOP 5 giây
→ tiến tiếp 15 cm
→ STOP 5 giây
→ lặp lại...

LiDAR, Hall Sync, khoảng cách MAX, thời gian MAX, L1/L2, máy mài/hút và các chức năng AUTO khác vẫn giữ nguyên.

Thay Cảm biến BNO086 bằng Mpu6050, thay LiDAR bằng cảm biến siêu âm JSN-SR04T

Có thể thay thành:

• BNO086 → MPU6050 để lấy góc hướng/yaw tương đối.
• LD14 → JSN-SR04T để đo một khoảng cách phía trước.
• Giữ nguyên Hall, AUTO ngắt quãng, Web, máy mài/hút.
• Vì JSN-SR04T chỉ đo phía trước, giao diện LiDAR 3 vùng nên đổi thành “CẢM BIẾN TRƯỚC” một giá trị.

Tuy nhiên có một điểm quan trọng: MPU6050 không có từ kế, nên yaw sẽ bị trôi theo thời gian, không ổn định tuyệt đối như BNO086. Với robot của bạn, Hall vẫn nên giữ nhiệm vụ cân hai bánh khi chạy thẳng; MPU6050 chủ yếu dùng để đo góc quay tương đối 90° trong thời gian ngắn.

Đặc biệt không nên để MPU6050 và Hall cùng liên tục sửa DAC khi xe chạy thẳng, vì hai bộ điều khiển có thể “đánh nhau”. Chạy thẳng hiện tại nên để Hall Sync làm chính; MPU6050 dùng cho góc quay.

Tôi có thể sửa trực tiếp toàn bộ file 2745 dòng bạn vừa gửi thành bản MPU6050 + JSN-SR04T, đồng thời đổi giao diện Web từ LiDAR TRÁI/GIỮA/PHẢI thành CẢM BIẾN TRƯỚC, giữ nguyên các phần còn lại

Lưu ý ECHO của JSN-SR04T thường là mức 5 V. Không đưa trực tiếp vào ESP32. Dùng chia áp, ví dụ:

JSN ECHO
   |
  4.7k
   |
   +-------- GPIO17 ESP32
   |
  10k
   |
  GND

TRIG từ GPIO16 → TRIG JSN có thể điều khiển trực tiếp.

 JSN-SR04T  ko chạy, tôi thay bằng HC-SR04, sửa lại code cho tôi, có thêm lọc 3–5 lần đo HC-SR04 để robot không STOP nhầm do một giá trị nhiễu đơn lẻ. Tôi khuyên dùng lọc 3 mẫu liên tiếp trước, vì robot cần phản ứng nhanh với vật cản. Với chu kỳ đo 60 ms, 3 mẫu chỉ tạo thêm khoảng 120 ms để xác nhận; 5 mẫu sẽ chậm hơn. Tôi cũng sẽ giữ giá trị khoảng cách HC-SR04 cập nhật bình thường trên Web; chỉ việc quyết định vật cản/STOP mới yêu cầu 3 lần liên tiếp. Cách này phù hợp hơn lấy trung bình 3–5 mẫu, vì lấy trung bình có thể làm vật cản gần bị giá trị xa trước đó kéo lên.

Bản mới:

• HC-SR04 đo mỗi 60 ms.
• Chỉ xác nhận vật cản khi có 3 lần đo liên tiếp nhỏ hơn hoặc bằng warningDistance.
• Một lần đo nhiễu đơn lẻ sẽ không STOP.
• Nếu có một mẫu hợp lệ trở lại vùng an toàn → bộ đếm về 0.
• Giá trị khoảng cách trên Web vẫn cập nhật theo từng lần đo.

Tôi sẽ dùng chính code V3.1 trong file anh vừa gửi làm code nền để sửa tiếp. Tôi đã kiểm tra: code đang dùng MPU6050 0x68, SDA GPIO21, SCL GPIO22, I2C 100 kHz Markdown đã dán (1), có calibration ban đầu, lọc gyro, nhận biết STILL, adaptive bias và tính Yaw

Tôi sẽ chuyển thành logic:

ROBOT STOP
    ↓
bánh thực sự dừng
    ↓
đợi ổn định
    ↓
Adaptive Bias = ON

CHẠY THẲNG
    ↓
Adaptive Bias = OFF
    ↓
targetYaw cố định
    ↓
MPU6050 sửa lệch trái/phải

QUAY 90°
    ↓
Adaptive Bias = OFF
    ↓
dùng Yaw đo góc quay

QUAY XONG
    ↓
STOP
    ↓
Adaptive Bias = ON
    ↓
ổn định offset
    ↓
lấy targetYaw mới

Như vậy sẽ giữ được kết quả bù drift rất tốt mà anh vừa test, nhưng tránh trường hợp robot đang quay chậm mà MPU6050 tưởng là đứng yên rồi học mất chuyển động quay.

Anh có thể coi file code vừa gửi là bản MPU6050 chuẩn hiện tại; các bước sửa robot tiếp theo tôi sẽ dựa trực tiếp trên bản này.

Tôi sẽ sửa đúng phần tính Yaw theo hướng:

Gyro Z RAW
   ↓
trừ Offset
   ↓
Yaw ← tích phân trực tiếp
   │
   └── Low-pass → chỉ dùng nhận biết STILL
                     ↓
              Adaptive Bias khi đứng yên

Như vậy sẽ tránh việc chuyển động quay chậm bị bộ lọc/deadband làm mất góc. Các phần Web, Hall, AUTO, HC-SR04, BLDC, máy mài, máy hút giữ nguyên.

----------------------------------------

Trong code hiện tại, khi robot chạy thẳng, tôi khuyên phân vai như sau:

Hall = điều khiển chính để 2 bánh chạy đều, còn MPU6050 = giám sát và hiệu chỉnh hướng tổng thể. Hai cái bổ sung cho nhau chứ không thay thế nhau.

Ví dụ robot bắt đầu chạy thẳng tại:

Yaw bắt đầu = 12.0°
Hall trái = 100
Hall phải = 100

Robot ghi lại 12.0° làm hướng mục tiêu. Khi chạy:

Hall trái/phải
      ↓
cân tốc độ/quãng đường 2 bánh
      ↓
Robot chạy tương đối thẳng
      ↓
MPU6050 kiểm tra góc thực tế
      ↓
Yaw lệch khỏi hướng ban đầu?
      ↓
hiệu chỉnh nhẹ bánh trái/phải

Hall xử lý sai lệch hai bánh

Code hiện tại đã có Hall Sync. Ví dụ:

Hall trái = 150
Hall phải = 146

→ bánh trái đã đi nhiều hơn → giảm nhẹ bánh trái hoặc tăng bánh phải.

Cái này xử lý rất tốt các nguyên nhân như hai động cơ khác tốc độ, đường kính bánh khác nhau, tải hai bên khác nhau.

Nhưng có trường hợp:

Hall trái = 150
Hall phải = 150

mà robot vẫn lệch hướng, chẳng hạn bánh trượt hoặc mặt nền làm robot xoay. Hall sẽ tưởng robot đang chạy hoàn toàn đúng.

Lúc này MPU6050 phát hiện được.

MPU6050 giữ hướng

Ngay khi bắt đầu chạy thẳng:

-------------------------------

Chế độ manu;

Đã sửa file tổng thể theo đúng logic mới:

• STOP: ga trái/phải = 0 → REVERSE_LEFT = LOW, REVERSE_RIGHT = LOW → đóng phanh.
• Bấm LÙI: 2 kênh Reverse cùng HIGH, sau đó bấm lùi lần 2 nhả phanh và 2 bánh chạy lùi ngay.
• Bấm TIẾN: 2 kênh Reverse về LOW rồi chạy tiến.
• AUTO vẫn giữ nguyên nguyên lý đã test.

• sửa ; Bấm PHẢI: LEFT=HIGH, RIGHT=LOW → phanh, Bấm PHẢI: → chạy 2 giây → cắt ga → phanh → vẫn giữ HIGH/LOW.

• TRÁI: LEFT=LOW, RIGHT=HIGH → phanh, Bấm TRÁI→ chạy 2 giây → cắt ga → phanh → vẫn giữ LOW/HIGH. (trái phải phải bấm 2 lần, lần 1 vào chế độ, lần 2 mới chạy, lần 3 nếu đang trong chế độ thì chạy tiếp, giống chế độ lùi)
• Bấm lần tiếp theo sẽ chạy tiếp 2 giây theo chiều đó.
• Bỏ hoàn toàn cơ chế nhấn giữ TRÁI/PHẢI.
• TIẾN, LÙI, STOP và AUTO không thay đổi.

Trong file vừa sửa, thời gian quay 2 giây 

const unsigned long TURN_RUN_TIME_MS = 2000;

nằm trong hai hàm motorLeft() và motorRight() ở dòng:

delay(TURN_RUN_TIME_MS);

tôi khuyên tạo một biến ở đầu chương trình:

const unsigned long TURN_RUN_TIME_MS = 2000;

Như vậy sau này muốn đổi thời gian quay chỉ cần sửa một chỗ, ví dụ 1500 = 1,5 giây.

--------------

bổ sung giữ hướng cho cả MANU, nhưng chỉ khi TIẾN hoặc LÙI. Khi người dùng bấm trái/phải thì phải tắt Heading Hold để robot được phép quay tự do

Ví dụ hướng ban đầu 0°, MPU phát hiện +2° thì điều chỉnh nhẹ hai bánh để kéo robot trở về 0°.

Khi STOP → tắt Heading Hold. Khi bấm TIẾN lại → lấy góc hiện tại làm hướng mới. Cách này rất phù hợp cho MANU vì người điều khiển vẫn có toàn quyền chọn hướng, MPU chỉ giúp giữ đường thẳng sau khi đã chọn hướng.

sửa bản code hiện tại để MANU TIẾN/LÙI = Hall Sync + MPU giữ hướng, còn TRÁI/PHẢI = MPU không can thiệp

Tôi kiểm tra code hiện tại thì bảng tốc độ thực tế là:

const float speedVoltage[6] = {
    1.20, 1.50, 1.80, 2.10, 2.50, 3.00
};

Ở MANU bây giờ:

• TIẾN/LÙI: Hall Sync + MPU6050 giữ hướng cùng hoạt động.
• Khi bắt đầu TIẾN/LÙI, MPU chốt góc hiện tại làm manualHeadingTargetDeg.
• MPU deadband ±0.5°, hệ số 0.015 V/°, giới hạn hiệu chỉnh ±0.15 V.
• TRÁI/PHẢI/STOP: MPU giữ hướng lập tức bị tắt.
• Nếu có chạy bù Hall trước, MPU chỉ chốt hướng sau khi bù Hall xong và cả hai bánh bắt đầu chạy.
• Hall và MPU được cộng thành một correction duy nhất trước khi xuất DAC, tránh hai bộ điều khiển ghi đè lên nhau.

Tôi đã kiểm tra file có 2971 dòng, dấu { } cân bằng.

Khi test MANU, bấm TIẾN bạn sẽ thấy Serial:

MANU HEADING TARGET = xx.xx deg (TIEN)

Sau đó thử tác động nhẹ làm robot lệch trái/phải. MPU phải kéo robot trở lại hướng lúc bắt đầu bấm TIẾN. Nếu thấy nó càng sửa càng lệch, báo tôi ngay; khi đó chỉ cần đảo dấu phần MPU correction, không phải sửa Hall.

Serial sẽ in 4 lần/giây khi MANU TIẾN/LÙI, dạng:

DBG MANU | TIEN | Target=0.00 | Yaw=-3.10 | YawErr=-3.10 |
Hall L=120 R=120 Err=0 |
HallCorr=+0.000V | MPUCorr=-0.047V |
Total=-0.047V | Out L=2.147V R=2.053V

Log này đã chỉ ra khá rõ nguyên nhân: MPU có hoạt động, nhưng Hall Sync đang triệt gần hết tác động của MPU.

Ví dụ tại Yaw = -5.31°:

HallCorr = +0.125 V
MPUCorr  = -0.080 V
-------------------
Total    = +0.045 V

MPU muốn sửa theo một hướng -0.080 V, nhưng Hall thấy hai bánh lệch 5 xung nên lập tức tạo +0.125 V theo hướng ngược lại. Kết quả MPU không đủ quyền làm hai bánh lệch tốc độ cần thiết để xoay robot trở về 0°.

Đây chính là vấn đề của việc yêu cầu đồng thời:

Cách tôi sẽ sửa

Khi góc gần đúng Hall hoạt động bình thường: 

Nhưng khi MPU phát hiện:

YawError = -5.31°

MPU sẽ tạo một Hall offset mục tiêu

nó có thể yêu cầu: L - R = -N xung

để robot thực sự cong trở lại hướng 0°.

Khi: Yaw → 0°

offset này tự giảm về 0 và Hall lại giữ hai bánh cân nhau.

DEBUG theo kiểu MPU đặt mục tiêu chênh lệch Hall, đây là phương án tôi chọn cho robot này.

Nguyên nhân là TargetDiff hiện đang được hiểu như chênh lệch Hall cố định tính từ đầu đoạn chạy. MPU cần một cơ chế tiếp tục tạo độ cong cho đến khi Yaw thực sự quay về mục tiêu, chứ không phải đạt 4 xung rồi hai bánh lại bằng nhau.

sửa TargetDiff thành mục tiêu Hall tích lũy theo sai số góc rồi test lại, cộng dồn đến khi nào Yaw → 0° thì mới dừng

→ bánh phải chạy nhiều hơn bánh trái → robot quay theo chiều ngược lại so với hiện tại.

Quan trọng là chỉ đảo dấu TargetDiff, không đảo HallCorr, không đổi dây Hall, không đổi chiều motor và chưa thay KI.

Chưa chỉnh KI=0.80 và giới hạn 30 xung lúc này. Cho robot chạy thực tế trước. Gửi tôi khoảng 15–30 dòng DBG INTEGRAL từ lúc robot bắt đầu lệch cho tới lúc nó sửa hướng; khi đó tôi sẽ chỉnh KI, deadband và giới hạn TargetDiff để robot sửa hướng êm, không zíc-zắc.

Chạy đã chuẩn

------------------------------

Chạy Auto;

Luồng AUTO hiện tại về cơ bản là:

Bấm AUTO
   ↓
Lấy góc hiện tại làm hướng gốc
   ↓
Bật máy mài + máy hút
   ↓
TIẾN
   ↓
15 cm → DỪNG 5 giây → TIẾN 15 cm → DỪNG 5 giây → ...
   ↓
Đến khoảng cách MAX hoặc gặp vật cản
   ↓
DỪNG
   ↓
QUAY PHẢI theo góc cài đặt (~90°)
   ↓
TIẾN L1
   ↓
QUAY PHẢI ~90°
   ↓
TIẾN theo đường kế tiếp
   ↓
Đến cuối đường
   ↓
QUAY TRÁI ~90°
   ↓
TIẾN L2
   ↓
QUAY TRÁI ~90°
   ↓
Lặp PHẢI → TRÁI → PHẢI → TRÁI...

Code hiện có state AUTO_FORWARD, dừng trước khi quay, AUTO_TURN_1, AUTO_SHIFT, AUTO_TURN_2; sau mỗi đường nó đảo autoTurnRight để lần tiếp theo chuyển từ phải sang trái hoặc ngược lại. Góc quay được xác định bằng MPU6050 theo chênh lệch yaw tương đối. Văn bản đã dán (1)

Có thêm hai giới hạn AUTO trên giao diện: Khoảng cách di chuyển MAX và Thời gian làm việc MAX; cùng các tham số góc trái/phải, L1/L2, khoảng cách mỗi bước và thời gian dừng. Khi hết thời gian làm việc, AUTO gọi stopAuto(), dừng motor và tắt phụ tải.

Nhưng có một điểm cần sửa trước khi test AUTO

Phần giữ hướng MPU + Hall tích lũy mà chúng ta vừa làm chuẩn hiện chỉ áp dụng cho MANU. Bản logic trước có điều kiện kiểu:

if(!autoMode && manualHeadingActive && mpuReady)

nên khi chuyển sang:

AUTO

cơ chế mới vừa test thành công không tự động được sử dụng cho đoạn AUTO_FORWARD.

Tôi đề nghị bước tiếp theo không thay đổi đường đi AUTO. Chỉ đưa bộ điều khiển vừa test chuẩn:

MPU6050
   ↓
Yaw error
   ↓
TargetDiff tích lũy
   ↓
Hall Sync
   ↓
L/R

vào cả các đoạn AUTO chạy thẳng.

Còn lúc AUTO_TURN_1 và AUTO_TURN_2 thì tắt giữ hướng thẳng, MPU chỉ dùng để đo góc quay. Sau khi quay xong và bắt đầu đoạn thẳng mới, lấy góc MPU lúc đó làm TargetYaw mới rồi kích hoạt lại MPU + Hall giữ hướng.

đưa bộ điều khiển vừa test chuẩn vào cả các đoạn AUTO chạy thẳng , Còn lúc AUTO_TURN_1 và AUTO_TURN_2 thì tắt giữ hướng thẳng, MPU chỉ dùng để đo góc quay. Sau khi quay xong và bắt đầu đoạn thẳng mới, lấy góc MPU lúc đó làm TargetYaw mới rồi kích hoạt lại MPU + Hall giữ hướng.

Đã sửa xong bản AUTO theo đúng yêu cầu và giữ nguyên bộ điều khiển MANU vừa test chuẩn.

Trong bản này:

• AUTO_FORWARD: dùng MPU → TargetDiff tích lũy → Hall Sync.
• Sau mỗi lần dừng 5 giây, khi chạy tiếp sẽ chốt Yaw hiện tại làm TargetYaw mới.
• AUTO_TURN_1: tắt giữ hướng thẳng; MPU chỉ đo góc quay.
• Sau TURN1, khi chạy AUTO_SHIFT L1/L2: chốt Yaw mới và bật lại giữ hướng.
• Trước AUTO_TURN_2: lại tắt giữ hướng.
• Sau TURN2: chạy đường mới → chốt Yaw mới và bật lại giữ hướng.
• Nếu có chạy bù Hall trước, TargetYaw chỉ được chốt sau khi bù xong và cả hai bánh bắt đầu chạy.
• Không dùng lại thuật toán updateAutoHeadingHold() cũ.

DEBUG giờ phân biệt rõ: 

File đã kiểm tra 3042 dòng, ngoặc {} cân bằng 230/230.

Khi test AUTO lần đầu, tôi khuyên theo dõi Serial ở đoạn chạy thẳng → TURN1 → L1/L2 → TURN2 → chạy thẳng mới. Nếu gửi log đó cho tôi, tôi sẽ kiểm tra toàn bộ chu trình AUTO và góc quay 90° cho bạn.

----------------------sửa auto chạy thẳng

Vì MANU hiện đã chạy chuẩn, phương án an toàn nhất là tôi sửa AUTO_FORWARD và AUTO_SHIFT dùng chính xác bộ điều khiển chạy thẳng của MANU, nhưng bỏ Hall pre-compensation riêng trong AUTO. Phần quay AUTO, 5 cm/dừng 5 giây, STOP, TIẾN/LÙI, TRÁI/PHẢI giữ nguyên.

Trong code gốc, motorForward() có cơ chế gọi startHallCompensation(false), tức có thể cho một bánh chạy bù trước rồi mới cho hai bánh chạy chung. Đây chính là phần chúng ta cần loại khỏi AUTO. Văn bản đã dán (1)

Tôi sửa thành:

• AUTO_FORWARD: bỏ Hall pre-compensation một bánh.
• AUTO_SHIFT L1/L2: cũng bỏ Hall pre-compensation.
• Mỗi lần AUTO chạy lại sau 5 giây: cũng bỏ pre-compensation.
• Hai bánh bắt đầu chạy cùng lúc → MPU + TargetDiff tích lũy + Hall Sync cân hai bánh.
• MANU giữ nguyên cơ chế hiện tại.
• LÙI, STOP, TRÁI/PHẢI, quay AUTO và các chức năng khác không sửa.
• Dấu hiệu chỉnh góc vừa sửa ở phiên bản trước vẫn được giữ.

Tôi đã kiểm tra có 4 vị trí motorForward() thuộc AUTO được chuyển sang chế độ bỏ pre-compensation. Ngoặc code cân bằng 232/232.

Khi test lại, quan trọng nhất là log sau mỗi lần bắt đầu AUTO. Hai Hall không nhất thiết bằng tuyệt đối, nhưng không được còn tình trạng kiểu L +0 / R +33 do chạy bù một bánh trước.

Cách mới hoạt động như sau:

Bước 5 cm đầu:
1.800V / 1.800V
→ phát hiện bánh phải nhanh
→ Hall Sync cân lại
→ ghi nhớ mức bù

Dừng 5 giây

Bước 5 cm tiếp:
áp dụng mức bù đã học NGAY khi khởi động
→ bánh trái được tăng
→ bánh phải được giảm
→ Hall Sync tiếp tục tinh chỉnh
→ cập nhật mức bù cho bước sau

Hướng xử lý 

LẦN N
Dừng
  ↓
Khởi động CẢ 2 bánh bằng dòng/điện áp đủ lớn
  ↓
Chạy 5 cm
  ↓
Đo:
- Hall trái
- Hall phải
- Góc MPU thay đổi
  ↓
Dừng 5 giây
  ↓
Tính mức bù cho LẦN N+1
  ↓
LẦN N+1 khởi động ngay với mức bù mới

Tôi còn đề nghị một thay đổi quan trọng: không capture lại TargetYaw sau mỗi lần dừng 5 giây. Giữ nguyên góc chuẩn của cả đường thẳng. Nếu không, MPU sẽ coi góc lệch mới là góc chuẩn và không thể sửa sai số tích lũy.

Chu trình mới:

LẦN N
  ↓
Khởi động bằng tốc độ đang chọn trên Web
  ↓
Chạy 5 cm
  ↓
Đo:
  Hall trái
  Hall phải
  Góc MPU so với TargetYaw
  ↓
Tính sai Hall
  ↓
Dừng 5 giây
  ↓
Tích lũy mức bù Hall
  ↓
LẦN N+1
khởi động NGAY với:
L = tốc độ Web - HallNext
R = tốc độ Web + HallNext

Nguyên lý mới là:

Bước N chạy
   ↓
Đo dL, dR
   ↓
StepDiff → cân tốc độ 2 bánh
   +
TotalDiff → kéo vị trí tích lũy về 0
   ↓
Nếu |TotalDiff| > 10
→ bắt đầu can thiệp sớm

Nếu |TotalDiff| > 20
→ tăng mạnh mức kéo về
   ↓
Giới hạn mỗi lần chỉnh ±0.20V
   ↓
Bước N+1 áp dụng ngay

Tôi đề xuất bảng bù startup như sau:

|StepDiff|       thay đổi bù cho lượt sau

0–1 Hall         0.00V
2–3 Hall         0.02V
4–5 Hall         0.04V
6–8 Hall         0.08V
9–12 Hall        0.15V
13–20 Hall       0.25V
>20 Hall         0.40V MAX

Vì lực khởi động của 2 bánh ko bằng nhau, khoảng thời gian quá ngắn đề chạy bù nên dù 1 cái 2.9 và 1 cái 1.2 vẫn ko bù nổi.

Đã sửa theo phương án vừa thống nhất:

Bản này:

• AUTO lần đầu: trái 2.90V – phải 1.20V.
• Dải AUTO: 1.20–2.90V.
• Chỉ cần mỗi bánh ≥ 5 Hall để kết thúc lượt học.
• Lượt sau học theo StepDiff = dL-dR, không dùng TotalDiff.
• Lệch lớn bù nhanh tối đa 0.40V/lượt, gần cân giảm xuống 0.15 → 0.08 → 0.04 → 0.02V.
• Hall Sync tức thời vẫn hoạt động trong lúc chạy.
• Dừng 5 giây vẫn giữ nguyên.

khởi động 2.26V trái / 1.34V phải luôn cho tôi

Với AUTO mới, tôi sẽ đổi logic như sau:

• Bù bên trái trên Web: đổi từ số xung Hall → điện áp cộng thêm cho động cơ trái, nhập 1 chữ số thập phân, ví dụ 0.5 V.
• Bù bên phải: tương tự, cộng điện áp cho động cơ phải.
• Điện áp AUTO:
  V_trái = tốc độ Web + Bù trái
  và V_phải = tốc độ Web + Bù phải.
• Khoảng cách di chuyển: mỗi lần AUTO tiến đúng số cm nhập trong ô Khoảng cách di chuyển trên Web, không cố định 10 cm nữa.
• Thời gian dừng: dừng đúng số giây nhập trong ô Thời gian dừng trên Web, không cố định 5 giây nữa.
• Lặp tiến → dừng → tiến → dừng... cho đến khi tổng quãng đường đạt Khoảng cách di chuyển MAX.
• AUTO không dùng hai ô bù này để bù Hall nữa. MANU và các chức năng khác giữ nguyên.
• Hai ô Bù bên trái / Bù bên phải sẽ cho phép nhập từ -3.0V đến +3.0V, bước 0.1V

• Điện áp trái = Tốc độ Web + Bù bên trái
  Điện áp phải = Tốc độ Web + Bù bên phải
  
  Bù trái/phải: -3.0V → +3.0V
  Bước điều chỉnh: 0.1V

Đã sửa đúng 2 ô:

• Bù bên trái: -3.00 → +3.00 V, bước 0.01V
• Bù bên phải: -3.00 → +3.00 V, bước 0.01V

Ví dụ có thể nhập +0.35V, -0.12V, +1.27V.

Quy trình AUTO mới là:

Tiến theo khoảng cách Web → STOP → kiểm tra góc MPU → nếu lệch ≤ ±0.5° thì bỏ qua; nếu lệch > ±0.5° thì hai bánh quay ngược chiều để cân về góc ban đầu → khi đạt ±0.5° mới bắt đầu đếm thời gian dừng Web → hết thời gian → chạy đoạn tiếp theo.

Góc chuẩn lúc bấm AUTO = 12.30°

Sau khi chạy:
12.65° → lệch +0.35° → bỏ qua
13.10° → lệch +0.80° → cân lại
11.50° → lệch -0.80° → cân lại

Khi cân, mục tiêu luôn là trở về:

12.30° ± 0.5°

chứ không lấy lại góc mới sau mỗi lần chạy.

Tôi thấy cách này phù hợp với mục tiêu giữ robot đi thẳng theo một hướng cố định ban đầu. Nếu robot chạy 100 chu kỳ thì cả 100 chu kỳ đều tham chiếu cùng một góc lúc bấm AUTO.

Đã sửa trực tiếp trên bản hiện tại và giữ nguyên AUTO cân góc, bù điện áp, MANU và các chức năng khác.

Bản mới có 2 HC-SR04 đặt cùng một hàng trên Web: bên trái dùng TRIG GPIO16 / ECHO GPIO17, bên phải dùng TRIG GPIO4 / ECHO GPIO5. Hai cảm biến được đọc xen kẽ để hạn chế nhiễu chéo. Chỉ cần một trong hai phát hiện vật cản nhỏ hơn hoặc bằng Khoảng cách cảnh báo đủ 3 lần liên tiếp thì chức năng an toàn sẽ STOP xe khi đang tiến.

Nút SAVE SETUP đã được đưa lên ngay phía trên dòng Bù bên trái. Khi SAVE, toàn bộ thông số Setup được lưu vào NVS/Preferences của ESP32, nên reset hoặc mất nguồn rồi bật lại vẫn giữ: Bù trái/phải, khoảng cách MAX, thời gian MAX, khoảng cách mỗi lần chạy, thời gian dừng, góc quay trái/phải, L1/L2 và khoảng cách cảnh báo.

Lưu ý chân ECHO của cả hai HC-SR04 là 5V, vẫn cần chia áp xuống khoảng 3.3V trước khi vào ESP32.

Thêm ô độ nghiêng và lấy giá trị cao nhất của Roll, Pitch vào chung 1 ô, đặt bên cạnh ô góc hướng, thêm dưới Khoảng cách cảnh báo là Độ nghiêng cảnh báo tính theo độ. Nếu độ nghiêng trên độ nghiêng cảnh báo thì stop tất cả

Đã giữ nguyên bản đang chạy ổn và bổ sung đúng phần độ nghiêng:

• Thêm ô ĐỘ NGHIÊNG ngay bên cạnh GÓC HƯỚNG.
• Giá trị hiển thị là MAX(|Roll|, |Pitch|).
• Thêm Độ nghiêng cảnh báo (độ) ngay dưới Khoảng cách cảnh báo.
• Giá trị này được SAVE vào NVS, reset/mất điện không mất.
• Nếu độ nghiêng vượt ngưỡng: STOP động cơ + dừng AUTO + tắt máy mài + máy hút.
• Có hysteresis 0.5° để tránh trạng thái cảnh báo rung liên tục quanh ngưỡng.
• Đặt Độ nghiêng cảnh báo = 0 thì chức năng này được tắt.

Ví dụ Roll 4.2°, Pitch 7.5° → Web hiển thị Độ nghiêng = 7.5°. Nếu cảnh báo đặt 6° → STOP tất cả.

-------------------------------------------------

Điện áp kích động cơ đang có các trường hợp sau:

MANU TIẾN và LÙI

Mức tốc độ Web:

const float speedVoltage[6] =
{
    1.20,
    1.50,
    1.80,
    2.10,
    2.50,
    3.00
};

MANU TIẾN và LÙI Hall/MPU có thể hiệu chỉnh tối đa: HALL_SYNC_MAX_CORR = 0.40V; theo cơ chế như nào

hiện tại MPU phát hiện robot lệch hướng thì yêu cầu cộng dồn dần hall lên (bản 6)

4. ±0.40V được đưa vào hai bánh như thế nào?

Code hiện tại:

leftVoltage  = baseVoltage - hallCorrection;
rightVoltage = baseVoltage + hallCorrection;

Ví dụ tốc độ đang đặt:

Base = 1.50V

Nếu:

HallCorr = +0.20V

thì:

TRÁI = 1.50 - 0.20 = 1.30V
PHẢI = 1.50 + 0.20 = 1.70V

Nếu đạt giới hạn tối đa +0.40V:

TRÁI = 1.10V
PHẢI = 1.90V

Nếu HallCorr = -0.40V:

TRÁI = 1.90V
PHẢI = 1.10V

Như vậy ±0.40V là mức hiệu chỉnh mỗi bánh, nên chênh lệch điện áp giữa hai bánh có thể lên tới:

0.40 + 0.40 = 0.80V.

Chuỗi điều khiển hiện tại

        MPU6050
           │
           ▼
     Sai góc Yaw
           │
           ▼
 Tạo TargetDiff Hall
           │
           ▼
 Hall trái ─── Hall phải
           │
           ▼
 ActualDiff - TargetDiff
           │
           ▼
 × 0.025 V/xung
           │
           ▼
 giới hạn ±0.40V
           │
      ┌────┴────┐
      ▼         ▼
 Trái -Corr   Phải +Corr

Điểm quan trọng là 0.40V chỉ là trần. Bình thường xe lệch ít thì có thể chỉ sửa 0.025V, 0.05V, 0.10V... Chỉ khi sai Hall đủ lớn mới chạm ±0.40V.

Với hiện tượng anh nói MANU lùi lâu thì lệch nhiều, tôi nghi cần xem chính phần MPU → TargetDiff khi LÙI, chứ chưa nên tăng 0.40V. Vì nếu dấu bù hoặc tốc độ tích lũy chưa đúng thì tăng lên 0.6–0.8V còn có thể làm lệch nhanh hơn.

const float MANUAL_HALL_DIFF_MAX_PULSE = 100.0f;    // anti-windup: gioi han target tich luy

Cơ chế mới của MANU TIẾN/LÙI:

Base trái  = Tốc độ Web + Bù bên trái
Base phải  = Tốc độ Web + Bù bên phải

            ↓
       MPU → TargetDiff
            ↓
       Hall Correction
            ↓

Out trái  = Base trái  - HallCorrection
Out phải  = Base phải + HallCorrection

Đã sửa theo đúng yêu cầu:

• Tilt > giới hạn phải liên tục đủ 500 ms mới STOP.
• Nếu Tilt tụt xuống dưới giới hạn trước 500 ms → bộ đếm hủy và tính lại từ đầu.
• Khi TILT STOP xảy ra, chương trình lưu lại chính giá trị Tilt gây STOP.
• Trên Web, dưới ĐỘ NGHIÊNG sẽ có thêm:
  TILT gây STOP: xx.x°
• Giá trị này được giữ lại kể cả sau khi MPU trở về góc bình thường.
• Serial sẽ báo dạng: