问题标签 [robotics]

我从事软件编程多年。多年来，我也对硬件编程（电路+机器人技术+等）感兴趣。

请建议我可以从哪里开始硬件编程。我的目标是将 s/w 和 h/w 结合起来一起工作。

我已经使用 Carmen http://carmen.sourceforge.net/有一段时间了，我真的很喜欢这个软件，但我需要在源代码中进行一些更改。

因此，我对一些与 Carmen 合作过的学生报告/项目或任何源代码文档很感兴趣。

我一直在阅读 Carmen 网页上的文档，但从各方面来说，我认为那里的文献有点过时和不足。

目前，我正在使用类 C 语言 (NXC) 来控制 LEGO MINDSTORMS 机器人。这种类 C 语言不支持泛型（或者，不是 C++，类。但我离题了）。但是，我在一本过时的 C++ 书中读到，C 或 C++ 都有一个名为 generic.h 的文件，其中包含用于执行此操作的有用的预处理器宏（即 name2 和 declare）。

有什么办法可以得到这个文件的副本吗？

我和几个朋友将构建简单的机器人来跟踪黑色表面上的白线，我们以前从未做过这种事情，我有非常高水平的攻击计划，

获得一个满足所有计算需求的迷你 atx 板、一个用于跟踪道路的网络摄像头和 2 个电动机，一个用于推进，一个用于方向。

我主要关心的是，有没有更好的方法来跟踪道路？或者网络摄像头是否适合这项工作？

编辑：

使用光敏电阻跟进答案似乎是要走的路，但我还有一个问题会有信号，在轨道的右侧告诉机器人转向哪个方向。又是黑底白字。比如我必须在丁字路口左转。有没有办法在没有相机的情况下处理这个问题？

我和我的朋友正在根据我之前关于如何在黑色表面上跟踪白线的问题构建一个线跟踪机器人。我们决定使用光敏电阻和 arduino 板。现在我发现的所有反射传感器都应该放置在非常靠近线上方 1-2 厘米的地方。现在我的一个队友和教授发生了激烈的争论，说有反射传感器可以跟踪 10 厘米或更多，但我们找不到。

是否有任何类型的传感器可以让我们追踪更远的线路？

嵌入式设备和机器人最需要的软件语言技能似乎是 C、C++ 和 LISP。为什么没有更新的语言进入这些应用程序？

例如，Erlang似乎特别适合机器人应用程序，因为它使并发编程更容易并允许代码热交换。 Python似乎很有用，如果不是因为它支持多种编程范式的话。我什至对 Java 没有涉足一般机器人编程感到惊讶。

我确信一个论点是，“一些较新的语言是解释的，而不是编译的”——这意味着编译语言更快并且使用更少的计算资源。在我们可以在手机或 SunSpot 上安装 Java 虚拟机的时代，情况仍然如此吗？（而且不是 LISP 还是被解释了吗？）

哪个是设计具有基础预测逻辑的避障系统的最佳算法？

我正在使用一个微波雷达系统，它可以给出各种障碍物的坐标和速度。基于这些输入，算法应识别最关键的障碍物并向汽车/飞机驾驶员发出警告。主要关注点是预测部分。系统不仅应该识别当前的障碍物，还应该根据速度分量寻找未来的碰撞。有哪些可能的探索策略（卡尔曼、扩展卡尔曼、神经网络、进化算法）

我目前正在 Microsoft Robotics Development Studio 中开展一个项目，但在部署通用解决方案时遇到了一些问题。

我的问题是这个。我正在做一个模拟，所以我需要将模拟引擎与我的项目一起部署。这取决于 Ageia PhysX 引擎、DirectX 和 Microsoft XNA 框架。我了解这一点，并且我了解 MRDS (dssdeploy) 的部署工具未设置为默认部署模拟。因此，如果有人以前使用过 MRDS，并且已经部署了模拟，我可以为此提供一些帮助。

我正在做与此类似的工作，但我在网上找到的可教练球员已经 3 岁，并且不能使用最新版本的足球服务器。

有谁知道任何替代品？或有什么建议？
谢谢

考虑自定义网络协议。此自定义协议可用于从基于 .NET 的中央工作站通过 LAN 控制机器人外围设备。（如果很重要，机器人正忙于在芯片生产环境中移动晶圆厂）。

• 对话中只有 2 方：.NET 站和机器人外围板
• 机器人端只能接收请求和发送响应
• .NET 端只能发起请求和接收响应
• 每个请求总是应该有一个响应
• 随后的请求可以一个接一个地紧跟，无需等待响应，但永远不会超过同时服务请求的固定限制（例如 5 个）

我与我的朋友（他拥有设计，我作为旁观者讨论过这件事）就所有好的细节和想法进行了详尽的讨论。在讨论结束时，我们对错过超时有强烈的分歧。我朋友的论点是双方的软件应该无限期地等待。我的论点是任何网络协议总是需要超时。我们根本无法达成一致。

我的一个理由是，如果发生任何故障，无论付出什么代价，你都应该“快速失败”，因为如果无论如何已经发生故障，恢复成本将继续与接收有关故障信息所花费的时间成正比增长。说在 LAN 上 1 分钟后，您绝对应该停止等待并发出一些警报。

但他的论点是，恢复应该包括修复失败的部分（在这种情况下是恢复网络连接），即使需要花费数小时才能确定网络丢失并修复，软件应该立即透明地继续运行重新连接 LAN 电缆后。

在这次讨论之前，我永远不会认真考虑永恒的协议。

哪一方的论点是正确的？“快速失败”还是“永不失败”？

编辑：失败的例子是通信丢失，通常由 TCP 层检测到。这部分也进行了讨论。如果 TCP 层返回错误，更高的自定义协议层将重试发送，并且没有关于它的参数。问题是：让下层继续尝试多久？

编辑接受的答案：答案比 2 个选择更复杂：“最常见的方法是永远不要放弃连接，直到实际尝试发送失败并确认连接已长期丢失。要计算连接已长期丢失，请使用心跳，但请保持损失年龄仅用于此确认，不用于立即警报“。

示例：当进行 telnet 会话时，您可以永远保持终端运行，并且您永远不知道在按 Enter 之间是否存在可被较低级别例程检测到的故障。