Giải quyết bài toán giao tiếp giữa các robot

Một phần của tài liệu Nghiên cứu thuật toán tìm đường bao phủ một nhóm robot di động (Trang 61)

4.2.1.Vấn đề phát sinh

Trong các thuật toán MSTC ở trên, về lý thuyết thuật toán đã mặc nhiên coi như các robot có thể thoái mái giao tiếp với nhau. Tuy nhiên, khi thử nghiệm thuật toán trong mô phỏng cũng như trong thực tế, vấn đề giao tiếp giữa các robot với nhau cũng là một vấn đề lớn cần quan tâm.

Trong môi trường mô phỏng, nếu chỉ mô phỏng trên một máy, việc giao tiếp này có thể xử lý đơn giản bằng cách lưu thông tin toàn cục vào đâu đó, ví dụ như lưu trong file. Trong quá trình làm luận văn này, cũng đã thử sử dụng ros bag để lưu thông tin về các trạng thái robot, các cell đã đi qua của các robot trong một file bag để các robot mô phỏng có thể truy cập. Việc sử dụng file như vậy có thể giải quyết tạm thời được vấn đề giao tiếp khi mô phỏng trong một máy, tuy nhiên, khi mô phỏng trên 2 hoặc nhiều máy khác nhau (mỗi máy là một robot, cùng chạy chung một bản đồ), hoặc cao hơn, khi chạy trong môi trường thực tế, việc sử dụng file để

4.2.2.Áp dụng lập trình socket với thuật toán MSTC

Sử dụng giao tiếp client-server theo mô hình khách-chủ để giao tiếp giữa các robot.

Hình 4.3: Mô hình client-server sử dụng

Với việc sử dụng một server chung để lưu các thông tin mà các robot cần thông báo cho các đồng nghiệp biết, số lượng kết nối cần thiết sẽ giảm đi so với trường hợp sử dụng mô hình ngang hàng. Khi triển khai trên thực tế, nếu điều kiện không cho phép, hoàn toàn có thể đặt server trên một client, tức là robot được máy tính đó điều khiển vừa chạy server, vừa chạy một thể hiện của client. Có thể hình dung việc này giống như robot đó đóng vai trò là “robot đầu đàn”,

Chức năng của server

Server tiến hành thực hiện các bước cần thiết để khởi tạo server. Sau khi khởi tạo để có thể tiếp nhận kết nối từ phía client thì server khởi tạo sẽ lưu hai biến cần thiết như biến status và old_cells. Biến status trên server lưu trạng thái của tất cả các robot. Nó nhiệm vụ quan trọng như lưu vị trí, trạng thái hay thời gian của từng robot. Biến status là một biến kiểu string, lưu lại trạng thái của toàn bộ robot đang hoạt động để biết robot đang ở đâu và trạng thái như thế nào và thời gian cập nhật. Mỗi trạng thái của từng robot cách nhau bởi dấu “;”, và chúng có dạng: tên robot, hoành độ của cell đang ở, tung độ của cell đang ở, trạng thái, thời gian cập nhật lần cập nhật cuối cùng của từng robot. Server biết các trạng thái của từng robot đó còn sống hay đã chết hay chưa dựa vào các cập nhật của từng robot trên từng thời điềm. Nếu quá 15 giây không có cập nhật của bất kỳ Client nào nó sẽ hiểu là robot đó đã chết và đưa ra trạng thái đó đến mọi robot. Dựa vào biến status để cập

nhật các old_cells. Biến old_cells để lưu các cell của tất cả robots đã đi qua. Nó được thêm vào khi mỗi robot đi vào cell mới. Dựa vào biến old_cells để tránh nhiều robot đi vào cùng một ô. Old_cells sẽ được cập nhật khi có bất kỳ robot nào chết. Server phân biệt các hành động trong tin nhắn từ client nhờ phần mã trong tin nhắn nhận được. Tin nhắn nhận được có dạng: “Mã|Dữ liệu”. Sau khi xử lý xâu, tùy vào đoạn mã nhận được mà server sẽ có hướng xử lý với đoạn dữ liệu phía sau cho thích hợp. Ý nghĩa một số tin nhắn từ client gửi lên server nói chung với mỗi thuật toán:

- [SAVE_STATUS]|Dữ liệu: Client yêu cầu lưu đoạn dữ liệu phía sau vào biến status trên server.

- [SAVE_OLD_CELLS]|Dữ liệu: Client yêu cầu lưu thêm đoạn dữ liệu phía sau vào biến old_cells trên server.

- [GIVE_ME_STATUS]|_: Client yêu cầu server trả về giá trị biến status của server

- [GIVE_ME_OLD_CELLS]|_: Client yêu cầu server trả về giá trị biến old_cells của server.

Hầu như các server trên các thuật toán là giống nhau chỉ khác thêm các công cụ hỗ trợ cho phù hợp với từng thuật toán. Ví dụ như thuật toán MSTC-Ofline thì nó chỉ cần lấy thông tin ban đầu và sau khi thực hiện xong thì nó kiểm tra con robot tiếp theo của nó trạng thái như thế nào.….

Các mã giả phía client trên các thuật toán

Sau khi áp dụng lồng ghép lập trình socket vào, thuật toán ORMSTC chạy trên mỗi robot (mỗi robot đóng vai trò là một client). Mỗi robot cũng giống như thuật toán 4 nó sẽ tạo một thuật toán để tạo các khởi tạo ban đầu. Từ thuật toán 4 có thể viết lại chính xác như sau:

Mã giả thuật toán 11 (pha khởi tạo): Thuật toán 11: Initialization()

1. Chạy hàm socket() 2. Chạy hàm connect()

3. Tính toán chia cell để biết starting_cell dựa trên starting_point

4. Khởi tạo biến status, biến current_cell và old_cells cục bộ trên mỗi robot 5. Gán current_cell = starting_cell

6. Thêm trạng thái của mình vào biến status của gửi lại lên server với yêu cầu lưu trạng thái

7. Thêm starting_cell của mình vào danh sách old_cells, sau đó gửi lên server với yêu cầu lưu old_cells

8. Lấy dữ liệu từ biến status và old_cells của các robot khác trên server xuống để đồng bộ dữ liệu cục bộ.

Giải thích mã giả thuật toán 11

Client tiến hành khởi tạo. Bước 1 và 2 gọi các hàm cần thiết để kết nối tới server. Sau đó tính toán từ vị trí ban đầu để biết cell bắt đầu của nó đang đứng. Thêm trạng thái của nó trên status của robot. Thêm các cell bắt đầu starting_cell thành cell cũ và lưu trên sever. Sau đó tiến hành lấy những giá trị mới nhất trên server về để đồng bộ với dữ liệu cục bộ. Việc trao đổi giữa Server và Client dựa trên các xâu ký tự nên từ đó ta sử dụng các xâu để lưu và xử lý. Ngoài ra, thay vì lưu mảng connection như trong thuật toán bên lý thuyết, ở phần code thử nghiệm, những kết nối này dưới dạng một biến string, đưa những xử lý về cập nhật kết nối về dạng xử lý xâu. Lý do là bởi không thể biết trước một robot có thể gặp bao nhiêu robot đồng nghiệp trong quá trình làm việc, bởi vậy việc khai báo toàn bộ các biến connection như trong lý thuyết là lãng phí và cũng không thể biết trước có bao nhiêu robot sẽ kết nối để khai báo. Bởi vậy, thay vì lưu nhiều giá trị trong mảng, khi thử nghiệm thuật toán, việc lựa chọn việc nối thêm giá trị hoặc thay đổi một phần giá trị vào biến string sau mỗi lần gặp. Như vậy có thể lưu được những kết nối cần thiết chỉ với hai biến.

Các thuật toán ở trên đã nêu trên, để thuật toán đó áp dụng trên thực tế cần áp dụng lập trình socket vào để tiến hành giao tiếp. Ý tưởng chung về lập trình trên

socket của nó đều giống nhau. Tuy nhiên, ở đây ta chỉ cần chỉ rõ ra những điểm cần thiết cần xử lý trong quá trình thực thi thuật toán:

- Thuật toán lưu trạng thái các robot lại: Khi robot đi vào các subcell trên mỗi bước đi của nó nó sẽ lưu lại trạng thái của nó. Trong đó, trạng thái được cập nhật lên server bao gồm:

 ALIVE: biểu thị trạng thái robot đang hoạt động bình thường

 DEAD: biểu thị trạng thái robot đã chết (adsbygoogle = window.adsbygoogle || []).push({});

 DONE: biểu thị trạng thái robot đã hoàn thành công việc

Nhờ việc lưu lại các trạng thái của chúng trên biến status của server, mỗi lần một robot cần kiểm tra xem một đồng nghiệp nào đó của nó còn sống hay không trên server, server dựa vào biến status để biết được con robot đó chết hay chưa và gửi trả lời đó đến các robot đang hỏi. Khi robot có biết câu trả lời là robot đang được hỏi đó đã chết, server cũng đồng thời xóa các cell đã đi của robot chết kia, cập nhật lại trạng thái là DEAD của robot kia thành DONE để tránh các lần hỏi sau này đến server. Chính vì vậy robot phải đồng thời cập nhật biến status và cập nhật old_cells trên server. Xóa các cell kết nối với robot đã chết kia khỏi danh sách quay lui.

- Thuật toán này dựa vào biến old_cells chung trên server để xác định những cell đã đi qua. Do đặc trưng của thuật toán là dựa trên cây bao trùm STC là nếu như toàn bộ khu vực làm việc chưa được bao phủ, khu vực đó nhìn tổng quan vẫn bẩn. Do mỗi robot có thể mới đi một vài subcell của một cell chứ chưa đi hết toàn bộ cell đó. Bởi vậy, như đã nói ở trên, khi có một robot chết, toàn bộ cell mà robot đó đã đi qua cần được loại bỏ các cell của robot đó khỏi old_cells, để robot khác có thể đảm nhiệm việc bao phủ khu vực đó, nhằm đảm bảo toàn bộ khu vực được bao phủ toàn bộ.

dàng. Tuy nhiên, khi thử nghiệm trong thực tế thì đây cũng là một vấn đề quan trọng cần xử lý. Cụ thể như sau:

- Khi tìm thấy cell quay lui của robot. Nếu sử dụng đường quay lui dựa đi quay lui dựa vào đường đã đi nếu gặp robot ở cuối đường đi thời gian sẽ lâu hơn. Nếu sử dụng với đường đi đó áp dụng với nhiều robot thì cứ mỗi lần nó quay lui xong và thực hiện xong công việc của của một robot chết thì nó phải trở vị trí ban đầu của nó. Lại thực hiện lại đường theo con đường nó đã đi thời gian sẽ lâu hơn.

- Khi một robot chết thì robot còn phải tránh robot trên nhưng trong thực tế có thể robot chết đứng giữa hai subcell với khoảng cách để laze với khích thước là D thì không thể biết robot đã chết là một chướng ngại vật khi thực hiện bao phủ hoàn toàn như hình dưới.

Việc quay lui được thực hiện để đảm bảo mục tiêu bao phủ hoàn toán. Đầu tiên tìm kiếm một đường đi từ cell của nó đang đứng đến cell mà nó gặp robot đã chết. Gọi cell đó là “ô bắt đầu mới”. Từ “ô bắt đầu mới” xây dựng đường đi bao phủ tất cả các vùng làm việc của robot đã chết.

4.3.2.Áp dụng phương pháp khoảng cách để di chuyển đến cell cần đi Mô tả Mô tả

Ý tưởng của phương pháp này dựa trên việc đơn giản hóa quá trình xử lý. Khi cần quay lui, thay đi theo đường đi ban đầu sẽ vướng vào khó khăn trên nên thực hiện khó khăn vì việc chạy đi chạy lại của robot đó. Thay vì cách trên ta sử dụng tìm đường đi trên các cell cũ của robot đó sao cho khoảng cách là ngắn nhất. Những cell cũ của robot này được lưu lại. Khi biết được cell mục tiêu cần di chuyển nó sẽ thực hiện tìm các cell xung quanh robot đó đứng mà là cell cũ của nó thì đi đến cell gần cell mục tiêu theo khoảng cách Manhatan. Và việc thực hiện lặp lại khi nó cần phải bao phủ thêm khu vực bao khủ của robot đã chết khác.

Sau khi gặp cell mục tiêu nó thực hiện thuật toán của nó đến tất cả cell còn lại cho đến khi bao phủ hoàn toàn nhưng nó có vấn đề phát sinh như ta đã nói trên. Đó là robot chết nằm ở giữa hai subcell hay cell nó đi vào subcell mà bị bao phủ một phần. Để tránh trường hợp đó. Sử dụng các biến điểm để lưu các vết của robot khi robot chuẩn bị chạy đến subcell mới nó sẽ lưu vết cell đó và thực hiện xóa vết khi nó đã đi xong.

Ưu điểm của phương pháp này:

- Chắc chắn tìm được đường quay lui cần thiết.

- Đảm bảo một số trường hợp thì đường đi ngắn nhất.

- Không trở về vị tri ban đâu của cell đó để quay lui đến cell mục tiêu để thực hiện bao phủ cho robot chết khác.

Nhược điểm của phương pháp này: - Tốn nhiều xử lý để tìm ra đường đi.

- Việc tính toán theo khoảng cách Manhatan khi gặp các nhánh cho đường đi khoảng cách ngắn nhưng nó trở thành đường cụt chính vì thế thời gian đôi lúc sẽ lâu hơn.

1. Lưu các cell đã đi của robot. Lưu vết subcell mà nó đang đứng.

2. Trong khi thực thi thuật toán MSTC ở phần trước khi gặp robot khác nó sẽ thực hiện lưu cell nó đang đứng.

3. Sau khi robot hoàn thành xong công việc của mình, nếu vẫn còn robot chưa hoàn thành công việc, định kỳ 15 giây kiểm tra xem có robot nào chết hay không.

4. Nếu có robot chết, kiểm tra nó có phải là robot mình đã gặp hay không, nếu đúng robot di chuyển đến cell mà đã gặp gọi là cell mục tiêu để thực hiện giúp đỡ cho robot đã chết này.

5. Với các cell đã đi của robot tìm kiếm đường đi theo khoảng cách Manhattan đến cell mục tiêu. Với mỗi lần đi, kiểm tra xem vị trí hiện tại thuộc cell mục tiêu hay chưa.

6. Nếu đã vào cell mục tiêu sử dụng thuật toán của nó đến các cell của robot đã chết. Dựa vào vết để tránh các subcell mà robot đã chiếm một phần. 7. Tiến hành giúp robot bị chết.

4.4. Vấn đề trong tính mạnh mẽ của thuật toán MSTC

Trong lý thuyết đã được giả định rằng, khi robot chết sẽ không làm cản trở các robot đang sống, bởi vậy thuật toán MSTC trong lý thuyết đảm bảo được tính mạnh mẽ.

Tuy nhiên, trong thực tế thì không phải vậy. Robot bị chết lúc này sẽ là vật cản, đặc biệt với thuật toán bao phủ không đầy đủ như thuật toán 5 và thuật toán 6 khiến cho toàn bộ cell mà nó đang nằm bị coi là vật cản và cell đó không thể đi vào được. Do đó sẽ ảnh hưởng khá nhiều tới các robot khác trong trường hợp các robot khác muốn giúp đỡ robot bị chết này. Thậm chí, trong tình huống đặc biệt, khi mà cell khởi đầu và cell mà robot chết tại đó bị trùng nhau, robot còn sống tuy đã quay lui lại để mong có thể giúp robot chết quét được một phần đường, nhưng cũng không thể giúp được gì. Tình huống được mô tả ở hình dưới đây là một minh họa cho tình huống này.

Hình 4.5: Tình huống robot còn sống không thể giúp robot đã chết

Trong tình huống mô tả ở trong hình trên, robot phía trên chết ngay tại điểm nút thắt. Cell đó có robot chết là vật cản nên cả cell đó bị coi là có vật cản và không thể đi vào. Lúc này, robot còn sống khác không thể giúp đỡ để bao phủ vùng làm việc của cell chết đó được. Thuật toán 7 trở nên được sẽ thực hiện được vì nó coi robot đã chết là vật cản và cũng thực hiện đi vào.

4.5. Kết quả thử nghiệm

4.5.1. Thử nghiệm trên môi trường mô phỏng: Sơ đồ hệ thống Sơ đồ hệ thống

Hình 4.6: Sơ đồ hệ thống khi triển khai trong môi trường mô phỏng (adsbygoogle = window.adsbygoogle || []).push({});

Mô tả môi trường mô phỏng

- Khu vực làm việc: Mô phỏng bằng Gazebo chạy với khu vực làm việc có kích thước 4Dx4D.

- Vật cản: Mô phỏng bằng Gazebo, có kích thước DxD. Có 3 vật cản trong khu vực làm việc.

- Robot: Mô phỏng robot Kobuki bằng Gazebo, kích thước robot là D.

- Laze: Mô phỏng laze Hokuyo gắn trên robot bằng Gazebo.

Cấu trúc chương trình:

Hình 4.7: Sơ đồ cấu trúc chương trình

- Tầng vật lý: Đóng vai trò giao tiếp với phần cứng, ánh xạ các tập lệnh, ghi nhận

và truyền thông điệp từ chương trình xuống bộ phận điều khiển robot. Tầng gồm các file launch: một file đơn giản giúp khởi động môi trường giao tiếp tới robot, một file giúp trao đổi tham số tới node và có cấu trúc cơ bản như sau:

- Các thẻ arg: Định nghĩa các đối số cung cấp thông tin về kích thước dụng cụ

Một phần của tài liệu Nghiên cứu thuật toán tìm đường bao phủ một nhóm robot di động (Trang 61)