Robot tự hành Wallace - Phần 4 - Thêm khoảng cách IR và cảm biến "Amp": 6 bước

2024 Tác giả: John Day | [email protected]. Sửa đổi lần cuối: 2024-01-30 13:34

Xin chào, hôm nay chúng ta bắt đầu giai đoạn tiếp theo của việc cải thiện năng lực của Wallace. Cụ thể, chúng tôi đang cố gắng cải thiện khả năng phát hiện và tránh chướng ngại vật bằng cách sử dụng cảm biến khoảng cách hồng ngoại, đồng thời tận dụng khả năng của bộ điều khiển động cơ Roboclaw để theo dõi dòng điện và biến nó thành một "cảm biến" ảo (phần mềm). Cuối cùng, chúng ta sẽ xem xét cách điều hướng mà không cần SLAM (vị trí và bản đồ đồng thời) (hiện tại), vì robot chưa có cảm biến IMU (đơn vị đo lường quán tính) hoặc ToF (thời gian bay).

Bằng cách điều hướng, ban đầu nó sẽ chỉ là hai mục tiêu chính:

1. tránh chướng ngại vật
2. nhận ra khi nó bị mắc kẹt ở đâu đó và không đạt được bất kỳ tiến bộ nào. ("tiến độ" có nghĩa là nó đã di chuyển về phía trước bất kỳ khoảng cách có ý nghĩa nào)
3. mục tiêu thứ 3 khả thi có thể là để nó cố gắng căn chỉnh thẳng hàng với một bức tường.

Dự án này bắt đầu với một bộ robot và các chuyển động cơ bản để hoạt động bằng bàn phím và kết nối ssh.

Giai đoạn thứ hai là bổ sung đủ mạch hỗ trợ để chuẩn bị cho việc bổ sung nhiều cảm biến.

Trong Có thể hướng dẫn trước, chúng tôi đã thêm một số cảm biến âm thanh HCSR04 và giờ đây rô bốt có thể tránh chướng ngại vật khi di chuyển xung quanh căn hộ.

Mặc dù nó hoạt động tốt trong nhà bếp và hành lang với bề mặt phẳng tốt và chắc chắn, nó hoàn toàn bị mù khi đến gần phòng ăn. Nó không thể "nhìn thấy" chân bàn ghế.

Một cải tiến có thể là theo dõi các dòng động cơ điển hình và nếu các giá trị này nhảy lên, thì rô bốt chắc chắn đã va phải thứ gì đó. Đó là một "kế hoạch B" hoặc thậm chí C. Nhưng điều đó không thực sự giúp nó điều hướng xung quanh khu vực ăn uống.

(Cập nhật: thực ra, hiện tại, giám sát hiện tại là phương án A khi lùi xe vì tôi đã tạm thời loại bỏ và cảm biến từ phía sau).

Video cho phần này là giai đoạn cuối cùng của cảm biến tránh chướng ngại vật.

Những gì bạn thấy trong video là sáu cảm biến âm thanh HCSR04 phía trước và hai cảm biến Sharp IR. Các cảm biến IR không phát huy nhiều tác dụng trong video. Sở trường của chúng chủ yếu là khi robot tự tìm đến khu vực ăn uống đối diện với chân bàn và ghế.

Ngoài các cảm biến, màn hình hiện tại cũng phát huy tác dụng đặc biệt trong quá trình lùi xe, trong trường hợp nó va vào một thứ gì đó.

Cuối cùng, nó sử dụng lịch sử của 100 lần di chuyển gần nhất và một số phân tích cơ bản để trả lời một câu hỏi:

"Gần đây có tiến bộ thực sự về phía trước không (hoặc nó bị mắc kẹt trong một số điệu nhảy lặp lại)?"

Vì vậy, trong video khi bạn thấy lặp lại tiến trình đảo ngược, sau đó nó quay lại, điều đó có nghĩa là nó đã nhận ra mô hình thuận-nghịch, do đó hãy thử một cái gì đó khác.

Mục tiêu được lập trình duy nhất của phiên bản phần mềm này là cố gắng đạt được tiến bộ liên tục về phía trước và cố gắng tránh các chướng ngại vật.

Bước 1: Thêm mạch hỗ trợ (MCP3008)

Trước khi có thể thêm các cảm biến IR, chúng tôi sẽ cần mạch giao diện giữa chúng và Raspberry Pi.

Chúng tôi sẽ thêm một bộ chuyển đổi tương tự sang kỹ thuật số MCP3008. Có rất nhiều tài nguyên trực tuyến về cách kết nối chip này với Raspberry Pi, vì vậy tôi sẽ không đi sâu vào đó ở đây.

Về cơ bản, chúng tôi có một sự lựa chọn. Nếu phiên bản của cảm biến IR hoạt động ở 3V, MCP3008 cũng vậy và sau đó chúng tôi có thể kết nối trực tiếp với Raspberry.

[Cảm biến hồng ngoại 3V] - [MCP3008] - [Raspberrry Pi]

Tuy nhiên, trong trường hợp của tôi, tôi đang chạy chủ yếu là 5V, vì vậy điều đó có nghĩa là một bộ dịch chuyển mức hai chiều.

[Cảm biến hồng ngoại 5V] - [MCP3008] - [Xe buýt hai chiều 5V-to-3V] - [Raspberry Pi]

Lưu ý: Chỉ có một đầu ra tín hiệu từ cảm biến IR. Nó đi trực tiếp đến một trong các đường tín hiệu tương tự đầu vào của MCP3008. Từ MCP3008, có 4 đường dữ liệu chúng ta cần kết nối (thông qua bus hai chiều) với Raspberry Pi.

Hiện tại, robot của chúng tôi sẽ chạy chỉ bằng hai cảm biến IR, nhưng chúng tôi có thể dễ dàng thêm nhiều hơn nữa. MCP3008 tám kênh đầu vào tương tự.

Bước 2: Gắn cảm biến hồng ngoại

Sharp tạo ra một số cảm biến IR khác nhau và chúng có phạm vi và vùng phủ sóng khác nhau. Tôi tình cờ đã đặt mua mô hình GP2Y0A60SZLF. Mô hình bạn chọn sẽ ảnh hưởng đến vị trí và hướng của cảm biến. Thật không may cho tôi, tôi đã không thực sự nghiên cứu chính xác loại cảm biến nào để lấy. Đó là quyết định "tôi có thể nhận được cái nào ở thời điểm và giá cả hợp lý từ một nguồn uy tín, trong số những cái mà họ cung cấp".

(Cập nhật: Tuy nhiên, điều đó có thể không thành vấn đề, vì các cảm biến này dường như bị nhầm lẫn bởi ánh sáng xung quanh bên trong. Tôi vẫn đang khám phá vấn đề đó)

Có ít nhất ba cách để gắn các cảm biến này vào robot.

1. Đặt chúng ở một vị trí cố định, ở phía trước, hướng ra xa nhau một chút.
2. Đặt chúng lên một servo, ở phía trước, hướng ra xa nhau một chút.
3. Đặt chúng ở một vị trí cố định, ở phía trước, nhưng ở góc ngoài cùng bên trái và ngoài cùng bên phải, nghiêng về phía nhau.

Khi so sánh lựa chọn số 1 với lựa chọn số 3, tôi nghĩ rằng số 3 sẽ bao gồm nhiều khu vực va chạm hơn. Nếu bạn xem các hình ảnh, lựa chọn số 3 có thể được thực hiện không chỉ để các trường cảm biến chồng lên nhau, mà còn có thể bao phủ trung tâm và ngoài chiều rộng bên ngoài của rô bốt.

Với lựa chọn số 1, các cảm biến càng được đặt lệch góc với nhau, thì càng có nhiều điểm mù ở trung tâm.

Chúng tôi có thể làm # 2, (tôi đã thêm một số hình ảnh với servo như một khả năng) và yêu cầu họ quét và rõ ràng điều này có thể bao gồm hầu hết các khu vực. Tuy nhiên, tôi muốn trì hoãn việc sử dụng servo càng lâu càng tốt, vì ít nhất hai lý do:

• Chúng tôi sẽ sử dụng hết một trong các kênh giao tiếp PWM trên Raspberry Pi. (Có thể cải thiện điều này nhưng vẫn…)
• Sức hút hiện tại với servo có thể rất đáng kể
• Nó bổ sung nhiều hơn cho phần cứng và phần mềm

Tôi muốn để lại tùy chọn servo sau này khi thêm các cảm biến quan trọng hơn, chẳng hạn như Time-of-Flight (ToF) hoặc có lẽ là một máy ảnh.

Có một lợi thế có thể có khác với lựa chọn số 2 mà không có ở hai lựa chọn còn lại. Các cảm biến IR này có thể bị nhầm lẫn, tùy thuộc vào ánh sáng. Có thể là robot đọc được một vật thể sắp xảy ra gần trong khi thực tế là không có vật thể ở gần đó. Với lựa chọn số 3, vì các trường của chúng có thể chồng lên nhau nên cả hai cảm biến đều có thể đăng ký cùng một đối tượng (từ các góc khác nhau).

Vì vậy, chúng tôi sẽ lựa chọn vị trí số 3.

Bước 3: Thời gian để kiểm tra

Sau khi chúng tôi đã tạo tất cả các kết nối giữa Raspberry Pi, MCP3008 ADC và cảm biến Sharp IR, đã đến lúc kiểm tra. Chỉ cần một bài kiểm tra đơn giản để đảm bảo hệ thống đang hoạt động với các cảm biến mới.

Như trong các bài giảng trước, tôi sử dụng thư viện wiringPi C càng nhiều càng tốt. Làm cho mọi thứ dễ dàng hơn. Có điều gì đó không rõ ràng khi xem xét trang web wiringPi, đó là có hỗ trợ trực tiếp cho MCP3004 / 3008.

Ngay cả khi không có điều đó, bạn chỉ có thể sử dụng phần mở rộng SPI. Nhưng không cần. Nếu bạn xem kỹ kho lưu trữ git của Gordon dành cho wiringPi, bạn sẽ bắt gặp danh sách các chip được hỗ trợ, trong đó một trong số đó là dành cho MCP3004 / 3008.

Tôi quyết định đính kèm mã dưới dạng tệp vì tôi không thể làm cho mã hiển thị chính xác trên trang này.

Bước 4: Một cảm biến ảo - AmpSensor

Bạn càng có nhiều cách khác nhau để robot nhận thông tin về thế giới bên ngoài thì càng tốt.

Robot hiện có tám cảm biến sonar âm thanh HCSR04 (chúng không phải là trọng tâm của Thiết bị hướng dẫn này) và hiện nó có hai cảm biến khoảng cách Sharp IR. Như đã nói trước đó, chúng ta có thể tận dụng một thứ khác: tính năng cảm biến dòng động cơ của Roboclaw.

Chúng ta có thể gói lệnh gọi truy vấn đó tới motor-controller thành một lớp C ++ và gọi nó là AmpSensor.

Bằng cách thêm một số "thông minh" vào phần mềm, chúng tôi có thể theo dõi và điều chỉnh dòng điện điển hình trong quá trình chuyển động thẳng (tiến, lùi) và cả chuyển động quay (trái, phải). Khi chúng ta biết các phạm vi amps đó, chúng ta có thể chọn một giá trị quan trọng, để nếu Bộ điều khiển cảm biến đo dòng điện từ bộ điều khiển động cơ vượt quá giá trị này, chúng ta biết các động cơ có thể đã bị đình trệ và điều đó thường cho thấy rô bốt đã bị va chạm vào một cái gì đó.

Nếu chúng tôi thêm một số tính linh hoạt vào phần mềm (args dòng lệnh và / hoặc nhập liệu bằng bàn phím trong quá trình hoạt động), thì chúng tôi có thể tăng / giảm ngưỡng "ampe tới hạn" khi chúng tôi thử nghiệm bằng cách chỉ để rô-bốt di chuyển và va vào vật thể, cả thẳng vào hoặc trong khi xoay.

Vì phần điều hướng của chúng tôi trong phần mềm biết hướng chuyển động, chúng tôi có thể sử dụng tất cả thông tin đó để có thể dừng chuyển động và cố gắng đảo ngược chuyển động trong một khoảng thời gian ngắn trước khi thử điều gì đó khác.

Bước 5: Điều hướng

Robot hiện bị giới hạn trong phản hồi trong thế giới thực. Nó có một vài cảm biến khoảng cách gần để tránh chướng ngại vật và nó có kỹ thuật dự phòng theo dõi dòng điện rút ra nếu cảm biến khoảng cách bỏ sót chướng ngại vật.

Nó không có động cơ với bộ mã hóa và không có IMU (đơn vị đo lường quán tính), do đó, điều này làm cho việc biết nó thực sự đang chuyển động hay đang quay và tốc độ là bao nhiêu.

Mặc dù người ta có thể nhận được một số dấu hiệu về khoảng cách với các cảm biến hiện có trên robot, nhưng trường nhìn của chúng rất rộng và không thể đoán trước được. Sonar âm thanh có thể không phản xạ lại một cách chính xác; tia hồng ngoại có thể bị nhầm lẫn bởi ánh sáng khác, hoặc thậm chí nhiều bề mặt phản chiếu. Tôi không chắc việc thực sự cố gắng theo dõi sự thay đổi về khoảng cách như một kỹ thuật để biết liệu rô bốt có đang di chuyển hay không và với tốc độ bao nhiêu và theo hướng nào.

Tôi đã cố ý chọn KHÔNG sử dụng bộ điều khiển vi mô như Arduino vì a) Tôi không thích môi trường psuedo-C ++, b) và việc phát triển quá nhiều sẽ làm hao mòn bộ nhớ đọc-ghi (?), Và tôi sẽ cần một máy tính chủ để phát triển (?). Hoặc có thể tôi chỉ xảy ra như Raspberry Pi.

Tuy nhiên, Pi chạy Raspbian không phải là hệ điều hành thời gian thực, vì vậy giữa sự không ổn định của các cảm biến này và hệ điều hành 'không đọc chính xác mọi lúc, tôi cảm thấy rằng mục đích của các cảm biến này phù hợp hơn cho việc tránh chướng ngại vật. đo khoảng cách thực tế.

Cách tiếp cận đó có vẻ phức tạp và không mang lại nhiều lợi ích, khi chúng ta có thể sử dụng các cảm biến ToF (thời gian bay) tốt hơn (sau này) cho mục đích đó (SLAM).

Một cách tiếp cận mà chúng ta có thể sử dụng là theo dõi một số loại lệnh chuyển động đã được đưa ra trong X giây cuối cùng hoặc các lệnh.

Ví dụ, giả sử rằng robot bị kẹt đối mặt với một góc theo đường chéo. Một bộ cảm biến cho nó biết rằng nó quá gần một bức tường, vì vậy nó xoay trục, nhưng sau đó bộ cảm biến khác cho nó biết rằng nó quá gần bức tường kia. Nó chỉ lặp lại một mô hình từ bên này sang bên kia.

Ví dụ trên chỉ là một trường hợp rất đơn giản. Thêm một số tính năng thông minh có thể chỉ nâng mô hình lặp lại lên một cấp độ mới, nhưng rô bốt vẫn bị mắc kẹt trong góc.

Ví dụ, thay vì xoay tới lui tại chỗ, nó quay một chiều, đảo ngược tạm thời (sau đó xóa các chỉ báo khoảng cách tới hạn) và ngay cả khi nó quay theo hướng khác, nó vẫn quay về phía trước ở một góc nào đó trở lại góc, lặp lại một mẫu phức tạp hơn về cơ bản của cùng một thứ.

Điều đó có nghĩa là chúng ta thực sự có thể sử dụng lịch sử các lệnh và xem cách khai thác và sử dụng thông tin đó.

Tôi có thể nghĩ ra hai cách rất cơ bản (thô sơ) để sử dụng lịch sử chuyển động.

• đối với X số lần di chuyển cuối cùng, chúng có khớp với Y patttern không. Một ví dụ đơn giản có thể là (và điều này đã xảy ra) "FORWARD, REVERSE, FORWARD, REVERSE,…..". Vì vậy, có hàm đối sánh này trả về TRUE (tìm thấy mẫu) hoặc FALSE (không tìm thấy). Nếu TRUE, trong phần điều hướng của chương trình, hãy thử các chuỗi chuyển động khác.
• đối với số lần di chuyển cuối cùng, là chuyển động chung hay chuyển động tịnh tiến. Làm thế nào người ta có thể xác định chuyển động tịnh tiến thực sự là gì? Chà.. một so sánh dễ dàng là đối với X di chuyển cuối cùng, "FORWARD" xảy ra nhiều hơn "REVERSE". Nhưng đó không phải là duy nhất. Làm thế nào về điều này: "RIGHT, RIGHT, LEFT, RIGHT". Trong trường hợp đó, robot phải rẽ phải để ra khỏi một góc hoặc vì nó đã tiếp cận bức tường ở một góc, điều đó có thể được coi là tiến bộ thực sự. Mặt khác, "LEFT, RIGHT, LEFT, RIGHT …" có thể không được coi là tiến độ thực sự về phía trước. Do đó, nếu "RIGHT" xuất hiện nhiều hơn "LEFT" hoặc "LEFT xuất hiện nhiều hơn" RIGHT ", thì đó có thể là tiến trình thực sự.

Ở phần đầu của Có thể hướng dẫn này, tôi đã đề cập rằng mục tiêu thứ 3 khả thi có thể là vuông góc hoặc thẳng hàng với một bức tường. Tuy nhiên, để làm được điều đó, chúng ta cần nhiều hơn là "chúng ta có đang ở gần một đối tượng nào đó không". Ví dụ: nếu chúng ta có thể có được hai cảm biến âm thanh hướng về phía trước (không phải trọng tâm của bài viết này) để cung cấp các phản hồi ổn định và tốt về khoảng cách, thì rõ ràng nếu một cảm biến báo cáo một giá trị khác nhiều so với cảm biến kia, thì rô bốt đã tiếp cận bức tường ở một góc và có thể thử một số thao tác để xem liệu các giá trị đó có tiếp cận nhau hay không (đối diện với bức tường theo hình vuông).

Bước 6: Kết luận, Giai đoạn tiếp theo…

Hy vọng có thể hướng dẫn này đã đưa ra một số ý tưởng.

Việc thêm nhiều cảm biến hơn sẽ mang lại một số lợi thế và thách thức.

Trong trường hợp trên, tất cả các cảm biến âm thanh hoạt động tốt cùng nhau và nó khá dễ hiểu với phần mềm.

Khi các cảm biến IR được đưa vào hỗn hợp, nó trở nên khó khăn hơn một chút. Lý do là một số trường nhìn của chúng trùng với trường nhìn của các cảm biến âm thanh. Các cảm biến IR có vẻ hơi nhạy và không thể đoán trước với điều kiện ánh sáng xung quanh thay đổi, trong khi tất nhiên các cảm biến âm thanh không bị ảnh hưởng bởi ánh sáng.

Và vì vậy, thách thức là phải làm gì nếu một cảm biến âm thanh cho chúng ta biết rằng không có vật cản nào, nhưng cảm biến IR thì có.

Hiện tại, sau khi thử-và-sai, mọi thứ kết thúc ở mức độ ưu tiên này:

1. cảm biến amp
2. Cảm biến hồng ngoại
3. cảm nhận âm thanh

Và những gì tôi đã làm chỉ là giảm độ nhạy của cảm biến IR, vì vậy chúng sẽ chỉ phát hiện các vật thể rất gần (chẳng hạn như chân ghế sắp xảy ra)

Cho đến nay, không cần phải thực hiện bất kỳ phần mềm đa luồng hoặc điều khiển gián đoạn nào, mặc dù đôi khi tôi gặp phải tình trạng mất kiểm soát giữa Raspberry Pi và bộ điều khiển động cơ Roboclaw (mất liên lạc nối tiếp).

Đây là nơi mà mạch E-Stop (xem Các tài liệu hướng dẫn trước) thường được sử dụng. Tuy nhiên, vì tôi không muốn (chưa) phải đối phó với việc phải đặt lại Roboclaw trong quá trình phát triển, và rô bốt hoạt động không nhanh như vậy và tôi có mặt để giám sát nó và tắt nó, tôi chưa đã kết nối E-Stop.

Cuối cùng, đa luồng rất có thể sẽ cần thiết.

Bước tiếp theo…

Cảm ơn bạn đã làm cho nó đến nay.

Tôi đã nhận được một số cảm biến VL53L1X IR laser ToF (thời gian bay), vì vậy đó rất có thể là chủ đề của Có thể hướng dẫn tiếp theo, cùng với một servo.