相当复杂的传感器网络
我最近正在从事一个项目，这是第一个涉及到足够使传感器网络复杂化的项目。最后，我认为沟通是整体绩效的瓶颈，我想知道更有经验的人会如何解决这个问题。这是一本长篇小说，但我认为这很有趣，因此请坚持使用。问题是设计一种自主飞艇，该飞艇能够导航障碍物路线并将乒乓球放入棕色盒子目标中。开始： 感测器 4D Systems uCAM-TTL摄像机模块-UART接口 HMC6352数字罗盘-I2C接口 Maxbotix Sonar ez4-1针模拟接口 执行器 2个L293D电动机驱动器（连接到简单的爱好电动机）-用于双向驱动6个电动机。他们需要PWM输入才能改变速度。现在，我们的3台电机始终在做相同的事情（控制上下运动的电机），因此它们仅需要我们控制器的2个PWM输出即可控制所有3台电机。其他3个控制横向运动的电机都需要单独控制（全向运动），因此我们的控制器还需要另外6个PWM输出。 伺服电机-PWM接口 控制器 由于稍后将变得清楚的原因，我们最终使用了2个ATmega328P。我们使用Arduino Uno对其进行编程（我们无法访问ISP），但是我们制造了定制PCB，因此我们不必使用arduino板，因为这只会给飞艇增加不必要的重量。至于我们为什么选择ATmega328P的原因，我对arduino环境非常熟悉，我认为这使代码开发变得更快，更容易。 通讯与处理 2个Xbee Basic 2个ATmega328P 带有OpenCV的运行C ++的台式计算机 因此，从相机模块可以看出，我们的大多数项目都依赖于计算机视觉。飞艇只能承载这么多的重量，而在微控制器上实现计算机视觉使我们感到不舒服。因此，我们最终要做的是使用XBee将图像数据中继回台式计算机。因此，在服务器端，我们接收到图像数据，并使用openCV处理图像并从中提取出东西。现在，服务器端还需要知道（来自声纳）的高度信息和指南针信息。 首先的麻烦是由于几个原因，我们无法使相机由微控制器控制。主要问题是uP上的内部存储器无法处理存储整个帧。通过聪明的编码可能有解决此问题的方法，但是出于这个问题的目的，让我们假装这是不可能的。因此，为了解决此问题，我们让服务器端通过XBee收发器发送摄像机命令，而XBee接收器（在飞船上）将其输出连接到摄像机的输入。 下一个难题是，单个ATmega328P上没有足够的PWM来控制所有电机，因为I2C接口使用PWM引脚之一（该死的...）。这就是为什么我们决定使用第二个。该代码实际上实际上完全适合于并行处理，因为高度控制完全独立于横向运动控制（因此2微米可能比连接到PWM控制器的1微米更好）。因此，U1负责2个PWM输出（向上/向下）并读取声纳。U2负责读取指南针，控制6个PWM输出（横向电机）以及读取声纳。U2还负责通过XBee从服务器接收命令。 这导致了我们的第一个沟通问题。XBee DOUT线已连接到微控制器和摄像机。当然，现在我们设计了一个协议，这样我们的微命令将忽略摄像头命令，而摄像头命令将忽略微命令，这样很好。但是，当忽略我们的微指令时，相机会在其输出线上发送回NAK数据。由于该命令是针对微型计算机的，因此我们需要某种方式来关闭相机输出到XBee的功能。为了解决这个问题，我们在相机和XBee（即第一个FET）之间以及在U2和XBee（即第二个FET）之间制作了微控2 FET。因此，当摄像机尝试将信息发送回服务器时，第一个FET为“开”，第二个FET为“关”。 因此，让您大致了解这是如何工作的几个示例： 服务器请求图片-PIC_REQUEST通过XBee到达U2和摄像机。U2会忽略它，并且相机会发回图像数据。 服务器刚刚完成图片处理，并正在发送电机数据以告诉飞艇右转-MOTOR_ANGLE（70）通过XBee进入并到达U2和摄像机。U2识别为微指令，因此关闭了相机的FET（但是相机可能已经响应了NAK？谁知道...）。然后，U2通过更改电动机PWM输出来响应命令。然后，它将相机的FET重新打开（这是默认设置，因为图像数据非常重要）。 服务器意识到我们已经到达障碍物路线的某个位置，默认悬停高度现在需要从90英寸而不是50英寸。SET_HEIGHT通过XBee，与示例2相同。U2识别SET_HEIGHT命令并在U1上触发中断。U1现在退出其高度控制循环，并等待从U2接收串行数据。是的，更多串行数据。此时，U2的FET处于打开状态（而相机的FET处于关闭状态），因此服务器将接收U2也发送到U1的高度。那是为了核实目的。现在，U1将其内部变量重置为height2HoverAt。U2现在关闭它的FET，然后重新打开相机的FET。 我肯定会遗漏大量信息，但是我认为这足以理解一些并发症。最后，我们的问题只是同步所有内容。有时缓冲区中会剩下数据，但是只有3个字节（我们所有的命令都是6个字节序列）。有时我们会失去与相机的连接，必须重新同步。 所以我的问题是：你们建议采用什么技术使所有这些组件之间的通信更可靠/更健壮/更简单/更好？ 例如，我知道有人会在板载XBee输出和摄像头之间添加一个延迟电路，以便微机有机会在用NAK响应微指令之前关闭摄像头的通话线路。还有其他想法吗？ 谢谢，我确定这将需要进行许多修改，敬请期待。 编辑1：对我们来说，通过微型镜之一拼接摄像机的UART数据似乎是不可能的。相机数据有两个选项：原始位图或JPEG。对于原始位图，相机会尽可能快地向您发送数据。ATmega328P仅具有128字节的串行缓冲区（从技术上讲这是可配置的，但我不确定如何配置），我们认为我们无法将其从缓冲区中取出并足够快地传送到XBee。这就留下了JPEG方法，该方法将它发送到每个包并等待控制器对其进行确认（小的握手协议）。最快速度为115200波特。现在由于某种原因，我们能够通过XBee可靠地传输大量数据的最快速度是57600波特（甚至在我们进行了节点/网络配对以允许自动重发功能之后）。在我们的网络中添加额外的停靠点（将摄像机连接到XBee的微型摄像机，而不是将摄像机连接到XBee的微型摄像机），只会减慢传输过多图像所需的时间。为了使电机控制算法正常工作，我们需要在图像上具有一定的刷新率。