Mạng cảm biến khá phức tạp

Tôi đã làm việc trên một dự án gần đây và đó là dự án đầu tiên có liên quan đủ để làm cho mạng cảm biến trở nên phức tạp. Cuối cùng, tôi nghĩ rằng giao tiếp là nút thắt về hiệu suất tổng thể và tôi tự hỏi làm thế nào nhiều người có kinh nghiệm hơn sẽ giải quyết vấn đề này. Đây là một bài đọc dài, nhưng tôi nghĩ nó khá thú vị vì vậy hãy gắn bó với nó. Vấn đề là thiết kế một cái nhìn tự động có khả năng điều hướng một chướng ngại vật và thả những quả bóng bàn vào các mục tiêu hộp màu nâu. Đây là:

Cảm biến

• Mô-đun camera uCAM-TTL của Hệ thống 4D - Giao diện UART
• La bàn kỹ thuật số HMC6352 - Giao diện I2C
• Maxbotix Sonar ez4 - Giao diện tương tự 1 pin

Thiết bị truyền động

• Trình điều khiển động cơ 2x L293D (kết nối với động cơ sở thích đơn giản) - Chúng được sử dụng để lái 6 động cơ hai chiều. Họ yêu cầu đầu vào PWM để thay đổi tốc độ. Bây giờ 3 động cơ của chúng tôi luôn làm điều tương tự (những động cơ điều khiển chuyển động lên / xuống) vì vậy chúng chỉ yêu cầu 2 đầu ra PWM từ bộ điều khiển của chúng tôi để điều khiển cả 3 động cơ. Cả 3 động cơ khác điều khiển chuyển động bên đều cần điều khiển riêng (đối với chuyển động đa hướng), do đó, cần có 6 đầu ra PWM khác từ các bộ điều khiển của chúng tôi.
• Động cơ servo - Giao diện PWM

Bộ điều khiển

Vì những lý do sẽ trở nên rõ ràng sau đó, chúng tôi đã kết thúc bằng cách sử dụng 2x ATmega328Ps. Chúng tôi đã sử dụng Arduino Uno để lập trình cho chúng (chúng tôi không có quyền truy cập vào ISP) nhưng chúng tôi đã sử dụng PCB tùy chỉnh nên chúng tôi không phải sử dụng bảng arduino vì điều đó sẽ tăng thêm trọng lượng không cần thiết cho tầm nhìn của chúng tôi. Về lý do tại sao chúng tôi chọn ATmega328P, tôi rất quen thuộc với môi trường arduino và tôi nghĩ rằng điều đó làm cho việc phát triển mã nhanh hơn và dễ dàng hơn nhiều.

Truyền thông & Xử lý

• Cơ bản gấp đôi Xbee
• 2 lần ATmega328P
• Máy tính để bàn chạy C ++ w / openCV

Vì vậy, như bạn có thể nói từ mô-đun máy ảnh, hầu hết dự án của chúng tôi dựa vào tầm nhìn máy tính. Các đốm sáng chỉ có thể mang rất nhiều trọng lượng và chúng tôi không cảm thấy thoải mái khi thực hiện thị giác máy tính trên một vi điều khiển. Vì vậy, những gì chúng tôi đã làm là sử dụng XBee để chuyển dữ liệu hình ảnh trở lại máy tính để bàn. Vì vậy, về phía máy chủ, chúng tôi đã nhận được dữ liệu hình ảnh và sử dụng openCV để xử lý hình ảnh và tìm ra thứ gì đó từ nó. Bây giờ phía máy chủ cũng cần biết thông tin chiều cao (từ sonar) và thông tin la bàn.

Nếp nhăn đầu tiên là chúng tôi không thể điều khiển máy ảnh bằng vi điều khiển vì một vài lý do. Vấn đề chính là bộ nhớ trong trên uP không thể xử lý lưu trữ toàn bộ khung. Có thể có nhiều cách xoay quanh vấn đề này thông qua mã hóa thông minh nhưng vì mục đích của câu hỏi này, hãy giả vờ là không thể. Vì vậy, để giải quyết vấn đề này, chúng tôi đã yêu cầu phía máy chủ gửi các lệnh camera qua bộ thu phát XBee và bộ thu XBee (trên boong tàu) có đầu ra được nối với đầu vào của camera.

Nếp nhăn tiếp theo là không có đủ số lượng PWM trên một ATmega328P để điều khiển tất cả các động cơ TRỞ THÀNH giao diện I2C sử dụng một trong các chân PWM (chết tiệt ...). Đó là lý do tại sao chúng tôi quyết định sử dụng cái thứ 2. Mã thực sự cho vay hoàn toàn để xử lý song song bởi vì điều khiển độ cao hoàn toàn độc lập với điều khiển chuyển động bên (vì vậy 2 micros có lẽ tốt hơn so với một gắn với bộ điều khiển PWM). Do đó, U1 chịu trách nhiệm cho 2 đầu ra PWM (lên / xuống) và đọc Sonar. U2 chịu trách nhiệm đọc la bàn, điều khiển 6 đầu ra PWM (động cơ bên) và cũng đọc Sonar. U2 cũng chịu trách nhiệm nhận lệnh từ máy chủ thông qua XBee.

Điều đó dẫn đến vấn đề giao tiếp đầu tiên của chúng tôi. Dòng XBee DOUT được kết nối với cả vi điều khiển và máy ảnh. Bây giờ tất nhiên chúng tôi đã thiết kế một giao thức để các lệnh micro của chúng tôi sẽ bỏ qua các lệnh camera và các lệnh camera sẽ bỏ qua các lệnh micro để điều đó ổn. Tuy nhiên, máy ảnh, khi bỏ qua các lệnh vi mô của chúng tôi, sẽ gửi lại dữ liệu NAK trên dòng đầu ra của nó. Vì lệnh này dành cho micro, chúng tôi cần một ngày nào đó để tắt đầu ra camera cho XBee. Để giải quyết vấn đề này, chúng tôi đã tạo ra 2 FET điều khiển vi mô nằm giữa máy ảnh và XBee (đó là FET đầu tiên) và giữa U2 và XBee (đó là FET thứ hai). Do đó, khi máy ảnh đang cố gửi thông tin trở lại máy chủ, FET đầu tiên đã 'bật' và FET thứ hai bị 'tắt'.

Vì vậy, để cung cấp cho bạn một ý tưởng về cách làm việc này ở đây là một vài ví dụ:

1. Máy chủ yêu cầu một hình ảnh - PIC_REQUEST đi qua XBee và đến U2 và máy ảnh. U2 bỏ qua nó và máy ảnh sẽ gửi lại dữ liệu hình ảnh.
2. Máy chủ vừa xử lý xong một bức ảnh và đang gửi dữ liệu động cơ để báo trước để rẽ phải - XE_ANGLE (70) đi qua XBee và đến U2 và máy ảnh. U2 nhận ra đó là một lệnh vi mô và do đó tắt FET của Camera (nhưng có lẽ máy ảnh đã phản hồi bằng NAK ?? ai biết ...). U2 sau đó đáp ứng lệnh bằng cách thay đổi đầu ra PWM của động cơ. Sau đó, nó bật lại FET của Camera (đây là cài đặt mặc định vì dữ liệu hình ảnh là quan trọng nhất).
3. Máy chủ nhận ra rằng chúng ta đã đi đến một điểm trong khóa học vượt chướng ngại vật nơi chiều cao di chuột mặc định của chúng ta bây giờ cần phải là 90 inch thay vì 50 inch. SET_HEIGHT đi qua XBee và điều tương tự xảy ra như trong ví dụ 2. U2 nhận ra lệnh SET_HEIGHT và kích hoạt ngắt trên U1. Bây giờ U1 ra khỏi vòng điều khiển chiều cao của nó và chờ nhận dữ liệu nối tiếp từ U2. Đúng vậy, nhiều dữ liệu nối tiếp hơn. Tại thời điểm này, FET của U2 được bật (và FET của máy ảnh tắt) để máy chủ nhận được độ cao mà U2 cũng đang gửi tới U1. Đó là cho mục đích xác minh. Bây giờ U1 đặt lại biến nội bộ của nó cho height2HoverAt. Bây giờ U2 tắt FET và bật lại FET của máy ảnh.

Tôi chắc chắn đã bỏ qua một lượng thông tin tốt nhưng tôi nghĩ rằng đủ để hiểu một số biến chứng. Cuối cùng, vấn đề của chúng tôi chỉ là đồng bộ hóa mọi thứ. Đôi khi sẽ có dữ liệu còn sót lại trong bộ đệm, nhưng chỉ có 3 byte (tất cả các lệnh của chúng tôi là chuỗi 6 byte). Đôi khi chúng tôi sẽ mất kết nối với máy ảnh của mình và phải đồng bộ lại nó.

Vì vậy, câu hỏi của tôi là: Các bạn muốn đề xuất những kỹ thuật nào để làm cho giao tiếp giữa tất cả các thành phần đó trở nên đáng tin cậy / mạnh mẽ / đơn giản / tốt hơn?

Ví dụ, tôi biết người ta sẽ thêm một mạch trễ giữa XBee trên bo mạch và máy ảnh để micro có cơ hội tắt dòng đàm thoại của máy ảnh trước khi nó phản ứng với các lệnh micro bằng NAK. Còn ý tưởng nào khác như thế không?

Cảm ơn và tôi chắc chắn rằng điều này sẽ yêu cầu nhiều chỉnh sửa vì vậy hãy theo dõi.

Chỉnh sửa1:Việc nối dữ liệu UART của máy ảnh thông qua một trong các micrô dường như không thể đối với chúng tôi. Có hai tùy chọn cho dữ liệu camera, bản đồ bit thô hoặc JPEG. Đối với một bitmap thô, máy ảnh chỉ gửi dữ liệu về bạn nhanh nhất có thể. ATmega328P chỉ có 128 byte cho bộ đệm nối tiếp (về mặt kỹ thuật, đây là cấu hình nhưng tôi không chắc bằng cách nào) và chúng tôi không nghĩ rằng mình có thể lấy nó ra khỏi bộ đệm và thông qua XBee đủ nhanh. Điều đó đã để lại phương thức JPEG nơi nó gửi từng gói và chờ bộ điều khiển ACK nó (protocl bắt tay nhỏ). Tốc độ nhanh nhất có thể đạt được là 115200 baud. Bây giờ vì một số lý do, tốc độ nhanh nhất mà chúng tôi có thể truyền một lượng lớn dữ liệu qua XBee là 57600 baud (điều này thậm chí sau khi chúng tôi đã ghép nối nút / mạng để cho phép khả năng tự động gửi lại). Thêm điểm dừng bổ sung trong mạng của chúng tôi (máy ảnh thành micro vào XBee, trái ngược với máy ảnh chỉ XBee) cho micro chỉ đơn giản là làm chậm thời gian cần thiết để truyền hình ảnh quá nhiều. Chúng tôi cần một tốc độ làm mới nhất định trên hình ảnh để thuật toán điều khiển động cơ của chúng tôi hoạt động.

Tôi hiểu rằng bạn muốn chọn một môi trường phát triển mà bạn quen thuộc để bạn có thể bắt đầu chạy, nhưng tôi nghĩ rằng sự đánh đổi phần cứng / phần mềm có thể đã ngăn cản bạn bằng cách gắn bó với Arduino và không chọn một phần có tất cả thay vào đó, các thiết bị ngoại vi phần cứng mà bạn cần và viết mọi thứ bằng C điều khiển ngắt.

Tôi đồng ý với đề xuất của @Matt Jenkins và muốn mở rộng về nó.

Tôi đã chọn một uC với 2 UART. Một kết nối với Xbee và một kết nối với máy ảnh. UC chấp nhận lệnh từ máy chủ để bắt đầu đọc camera và một thói quen có thể được viết để truyền dữ liệu từ kênh UART của máy ảnh sang kênh UART XBee trên cơ sở byte trên mỗi byte - vì vậy không có bộ đệm (hoặc nhiều nhất chỉ là rất nhỏ một) cần thiết. Tôi đã cố gắng loại bỏ tất cả các uC khác bằng cách chọn một phần cũng đáp ứng tất cả các nhu cầu về PWM của bạn (8 kênh PWM?) Và nếu bạn muốn gắn bó với 2 uC khác nhau thì hãy chăm sóc trục tương ứng của chúng giao diện truyền thông khác nhau sẽ tốt hơn vì tất cả các UART khác của bạn sẽ được thực hiện.

Một số người khác cũng đề nghị chuyển sang nền tảng linux nhúng để chạy mọi thứ (bao gồm openCV) và tôi nghĩ đó cũng là điều cần khám phá. Mặc dù tôi đã ở đó trước đó, một dự án trường học 4 tháng và bạn chỉ cần hoàn thành nó càng sớm càng tốt, không thể bị đình trệ khi bị tê liệt bởi phân tích - mặc dù vậy, tôi hy vọng nó sẽ tốt cho bạn!

EDIT # 1 Trả lời các bình luận @JGord:

Tôi đã thực hiện một dự án triển khai chuyển tiếp UART với ATmega164p. Nó có 2 UART. Dưới đây là hình ảnh từ bản chụp phân tích logic (bộ phân tích logic USB Saleae) của dự án đó hiển thị chuyển tiếp UART:

Dòng trên cùng là dữ liệu nguồn (trong trường hợp này sẽ là máy ảnh của bạn) và dòng dưới cùng là kênh UART được chuyển tiếp đến (XBee trong trường hợp của bạn). Các thường trình được viết để làm điều này xử lý ngắt nhận UART. Bây giờ, bạn có tin rằng trong khi quá trình chuyển tiếp UART này đang diễn ra, bạn có thể vui vẻ định cấu hình các kênh PWM của mình và xử lý các thói quen I2C của mình không? Hãy để tôi giải thích làm thế nào.

Mỗi thiết bị ngoại vi UART (đối với mọi phương tiện AVR của tôi) được tạo thành từ một thanh ghi dịch chuyển đôi, thanh ghi dữ liệu và thanh ghi điều khiển / trạng thái. Phần cứng này sẽ tự làm mọi thứ (giả sử rằng bạn đã khởi tạo tốc độ truyền và như vậy) mà không cần bất kỳ sự can thiệp nào của bạn nếu:

1. Một byte đến hoặc
2. Một byte được đặt trong thanh ghi dữ liệu của nó và được gắn cờ cho đầu ra

Điều quan trọng ở đây là thanh ghi thay đổi và thanh ghi dữ liệu. Giả sử một byte xuất hiện trên UART0 và chúng tôi muốn chuyển tiếp lưu lượng đó đến đầu ra của UART1. Khi một byte mới đã được chuyển sang thanh ghi dịch chuyển đầu vào của UART0, nó sẽ được chuyển sang thanh ghi dữ liệu UART0 và ngắt nhận UART0 bị tắt. Nếu bạn đã viết ISR cho nó, bạn có thể lấy byte trong thanh ghi dữ liệu UART0 và chuyển nó sang thanh ghi dữ liệu UART1 và sau đó đặt thanh ghi điều khiển cho UART1 để bắt đầu truyền. Những gì nó làm là yêu cầu thiết bị ngoại vi UART1 lấy bất cứ thứ gì bạn vừa đưa vào thanh ghi dữ liệu của nó, đưa nó vào thanh ghi dịch chuyển đầu ra của nó và bắt đầu chuyển nó ra. Từ đây, bạn có thể quay trở lại từ ISR của mình và quay trở lại bất kỳ nhiệm vụ nào mà uC của bạn đang làm trước khi nó bị gián đoạn. Bây giờ là UART0, sau khi chỉ cần xóa thanh ghi thay đổi và xóa thanh ghi dữ liệu có thể bắt đầu dịch chuyển dữ liệu mới nếu nó chưa được thực hiện trong ISR và UART1 đang dịch chuyển byte bạn vừa đặt vào - tất cả điều đó xảy ra không có sự can thiệp của bạn trong khi uC của bạn không thực hiện một số nhiệm vụ khác. Toàn bộ ISR mất vài giây để thực thi vì chúng ta chỉ di chuyển 1 byte xung quanh một số bộ nhớ và điều này sẽ khiến bạn mất nhiều thời gian để làm những việc khác cho đến khi byte tiếp theo trên UART0 xuất hiện (mất 100 giây micro giây). và UART1 đang chuyển hết byte mà bạn vừa đặt vào nó - tất cả điều đó tự xảy ra mà không cần sự can thiệp của bạn trong khi uC của bạn không thực hiện một số nhiệm vụ khác. Toàn bộ ISR mất vài giây để thực thi vì chúng ta chỉ di chuyển 1 byte xung quanh một số bộ nhớ và điều này sẽ khiến bạn mất nhiều thời gian để làm những việc khác cho đến khi byte tiếp theo trên UART0 xuất hiện (mất 100 giây micro giây). và UART1 đang chuyển hết byte mà bạn vừa đặt vào nó - tất cả điều đó tự xảy ra mà không cần sự can thiệp của bạn trong khi uC của bạn không thực hiện một số nhiệm vụ khác. Toàn bộ ISR mất vài giây để thực thi vì chúng ta chỉ di chuyển 1 byte xung quanh một số bộ nhớ và điều này sẽ khiến bạn mất nhiều thời gian để làm những việc khác cho đến khi byte tiếp theo trên UART0 xuất hiện (mất 100 giây micro giây).

Đây là nét đẹp của việc có các thiết bị ngoại vi phần cứng - bạn chỉ cần ghi vào một số thanh ghi ánh xạ bộ nhớ và nó sẽ chăm sóc phần còn lại từ đó và sẽ báo hiệu cho sự chú ý của bạn thông qua các ngắt như tôi vừa giải thích ở trên. Quá trình này sẽ xảy ra mỗi khi một byte mới xuất hiện trên UART0.

Lưu ý rằng chỉ có độ trễ 1 byte trong quá trình ghi logic vì chúng ta chỉ "đệm" 1 byte nếu bạn muốn nghĩ về nó theo cách đó. Tôi không chắc chắn làm thế nào bạn đưa ra O(2N)ước tính của mình - Tôi sẽ giả định rằng bạn đã đặt các chức năng thư viện nối tiếp Arduino trong một vòng lặp chờ dữ liệu. Nếu chúng ta tính đến chi phí phải xử lý lệnh "camera đọc" trên uC, thì phương thức điều khiển ngắt giống như O(N+c)trong đó cbao gồm độ trễ byte đơn và lệnh "camera đọc". Điều này sẽ cực kỳ nhỏ nếu bạn gửi một lượng lớn dữ liệu (dữ liệu hình ảnh phải không?).

Tất cả các chi tiết này về thiết bị ngoại vi UART (và mọi thiết bị ngoại vi trên uC) được giải thích kỹ lưỡng trong biểu dữ liệu và tất cả đều có thể truy cập được trong C. Tôi không biết liệu môi trường Arduino có cho bạn mức truy cập thấp để bạn có thể bắt đầu truy cập không các thanh ghi - và đó là điều - nếu nó không bị giới hạn bởi việc thực hiện chúng. Bạn có thể kiểm soát mọi thứ nếu bạn đã viết nó bằng C (thậm chí nhiều hơn nếu được thực hiện trong lắp ráp) và bạn thực sự có thể đẩy vi điều khiển đến tiềm năng thực sự của nó.

Tại sao bạn không thể chuyển dữ liệu máy ảnh thông qua các PatrickC? Tôi không có nghĩa là đệm các hình ảnh, nhưng chuyển tiếp dữ liệu UART thông qua PhaC để nó có thể quyết định những gì nên gửi lại và những gì không nên?

Dễ nhất nếu bạn có một loạiC có hai UART, nhưng có thể được mô phỏng trong phần mềm.

Một lựa chọn khác đã xảy ra với tôi, nhưng điều này có thể hơi cồng kềnh và quá nặng nề cho dự án của bạn: -

• Tại sao không sử dụng máy chủ USB không dây, được liên kết với một bộ chia USB nhỏ, với bộ điều hợp USB-> RS232 để cung cấp nhiều kênh điều khiển cho các phần khác nhau của hệ thống?

Đúng, cồng kềnh, nhưng nếu bạn gỡ chúng xuống và có thể sử dụng USB thay vì RS232 nếu có thể, bạn có thể thoát khỏi nó ...