听起来您有以下信息需要传达给用户：
还有其他一些注意事项：
连续或离散反馈。您是否有来自机器人的当前值的持续实时反馈？或者是离散反馈，机器人只有在达到目标后才发送当前值？显然连续对用户来说更好，因为它可以让用户区分机器人是慢还是被卡住，但如果你没有它，你已经找到了一种没有它的生活。
同步或异步命令发送。如果命令是同步发送的（即，在知道收到最后一个命令之前不会发出新命令），那么用户可能需要一种方法来（a）强制执行下一个命令而不等待前一个命令的回复（以防回复丢失），以及 (b) 在创建和发送命令之间的情况发生变化的情况下取消排队的命令。
有或没有冲突解决的机器人。机器人是否有逻辑在它收到的命令列表中向前看并解决冲突的命令？例如，如果它处于停止状态，并且其接收到的命令队列包括一个以 5 m/s 的速度运行的命令，然后是一个以 2 m/s 的速度运行的命令，它是否足够聪明地删除 5 m/s 的命令？还是会先尝试加速到 5 m/s，然后再加速到 2 m/s，可能会导致超调？它会等到达到 5 m/s 才“查看” 2 m/s 命令吗？缺乏冲突解决会使您的 UI 变得复杂，因为用户可能必须跟踪发送的所有命令才能了解机器人为何如此行事。
带有位置编码控制的集成信息
假设机器人有冲突解决和异步命令发送。我建议您不要将命令值、目标值和当前值单独控制，而是将它们全部集成到一个控件中，以便用户轻松比较当前值、目标值和命令值，并查看差异。也许最好的方法是通过窗口中的位置来表示值。这种值的位置编码在显示事物之间的关系方面是无与伦比的。有两个标准的 GUI 控件，单选按钮和滑块，可以完成这样的位置编码。但是，您必须增强它们以满足您的目的。最好的可用性可能需要定制的位置编码控件，您可以在其中示意性地表示机器人和可能的环境，并允许用户通过直接操作来控制它。但是，我假设您需要一个易于开发的实现，并且布局合理的滑块和单选按钮组合可能会让您非常接近这个理想。
使用单选按钮设置分类值，使用滑块设置数值。滑块可能包括一个文本框以允许用户微调该值。您可以扩充这些控件中的每一个，以便它们同时显示命令值、目标值和当前值。 “通常”指示器（单选按钮的圆点和滑块的手柄）表示命令值，而单独的图形指针表示当前值和目标值。通过使电流更加突出来区分电流和目标。我将它们设计成当它们处于相同值时合并为一个指针，以最大程度地减少通常情况下的混乱。如果您的用户没有在系统上接受过培训，您可能希望在指针上包含文本标签（“当前”和“目标”，当目标与当前不同时）。
使用这些位置编码控件，用户可以轻松比较当前值、目标值和命令值并查看差异。状态隐含在指标的相对位置中。当目标指针移动到命令位置时，用户知道命令已收到。当前指针指向目标时，机器人已达到指令值。这对于数值的连续反馈特别有用，因为用户不仅可以在滑块上看到当前值和目标值之间的差异，还可以通过查看指针关闭的速度来估计达到目标需要多长时间在目标上。对于单选按钮，您可以在目标指针旁包含“X% Done”文本，以指示何时实现目标（如果此信息可用）。
对于响应速度最快的 UI，更改滑块或单选按钮的值应立即发送命令。没有“应用”按钮。用户可以通过重新单击适当的滑块位置或单选按钮随时重新发送命令值。我想你会发现，当你面对一个明显没有反应的控件（考虑电梯按钮）时，这是一种自然的人类倾向。
如果响应通常很慢（超过几秒钟，因此用户的注意力可能已经转移到其他地方），目标指针和命令指示器之间的差异可能过于微妙，无法表示没有接收到命令。如果是这种情况，您可能希望在几乎可以肯定地表明命令在传输中丢失的超时时间之后包含一个非模式警报。无模式警报可以包括控件旁边的文本信号器和/或以图形方式突出显示命令目标的差异。根据严重程度，您可能希望使用蜂鸣声或动画等声音警报来加速吸引用户注意力。无论出于何种原因，当目标值与命令值匹配时，无模式警报会自动消失。
命令和电流的单独控制
如果滑块和单选按钮占用太多空间（或有其他问题），您可以使用单独的非位置编码控件来控制命令值和当前值，正如禁用按钮设计所暗示的那样。但是，总体而言，这是一个更具挑战性的设计，需要解决的问题更多。
我更喜欢文本框、复选框和下拉菜单等字段控件，而不是命令按钮，以便清楚地显示命令值。连续数字属性可能包括带有文本框的微调器按钮，如果它最终不会用增量命令阻塞队列。与上述选项一样，更改值会立即发送命令。
您担心使用计时器和禁用是正确的。除了使系统变得迟钝的问题外，这意味着您将命令状态变灰。这可能会使其难以阅读，并且还需要用户进行一些心理体操来解释（“它不可用，所以这意味着我已经选择了它”）。解释也可能模棱两可，因为通常禁用意味着不适用（例如，速度控制被禁用，因为机器人已降低稳定器以进行固定底座操作）。
解决方案是使用其他一些图形反馈而不是禁用。我会远离颜色编码。颜色编码往往是任意的，因此令人困惑（例如，红色是否意味着排队或超时？）。这可能是使用动画的（罕见的）好地方之一，因为动画直观地表示正在进行的过程。命令值控件的闪烁或跳动边框（或其他特征）可以指示已发送的命令正在等待回复。 current-value 控件的闪烁/跳动边框表示已收到命令并且机器人正在寻找目标值。如果动画在这种情况下会分散注意力（就像大多数其他情况一样），那么考虑用虚线边框（相对于实线）表示等待回复或寻找目标；虚线表示暂时或暂时的状态。
目标值和状态由动画所暗示。如果命令值边框是动画的，则里面的值是待处理的——尚未收到回复。如果当前边框单独动画，则命令控件内的值是目标值。如果两个边界都是动画的，那么机器人正在寻找一个（未指定的）目标值，而另一个正在等待。如果您认为在这种情况下不指定目标是有问题的，那么您可能需要 三个 控件来区分命令、目标和当前。但是，如果这是一种极端情况，最好在鼠标悬停当前值控件或使用下拉按钮时显示目标值。
如果反馈是连续的，您还可以定期更新数值属性的当前值（大约每 200 到 500 毫秒），因此此动画提供了机器人寻找目标的额外反馈。对于任何属性，如果机器人需要 10-15 秒或更长时间才能到达共同目标并且机器人有冲突解决，您可能还希望在当前属性控件内或旁边显示一个进度条，以便用户判断何时机器人将达到目标值。
要重新发送命令，用户可以随时重新选择一个值，或者在焦点位于命令控件上时按 Enter。对于某些控件（例如复选框）来说，这有点奇怪和尴尬，所以我还会考虑在命令超时回复时出现在控件附近的无模式通知（不是弹出窗口）。该通知包括一个重新发送命令的按钮。
如果您的用户未接受过系统培训，您可能希望在动画下包含冗余文本（例如，等待回复时的“发送”和朝着目标值移动时的“寻找”）。
日志表
如果命令是同步发送和/或机器人缺乏冲突解决方案，那么记录方法可能是最好的。这样，用户可以跟踪命令队列以发送命令或机器人接收到的命令，以预测机器人行为。但是，我不会让它成为一个只读文本框，而是一个可以操作的表格。虽然默认情况下按时间戳对表进行排序，但属性、命令值、状态（待处理、正在搜索、已实现、超时）将有单独的可排序字段。如果反馈是连续的，则状态应指示实现目标值的进度（例如百分比或进度条）。
如果有同步命令发送，那么用户可以编辑未决命令的命令值或强制前进、移动或删除未决命令。在任何情况下，都可以复制和重新插入命令，以便随时重新发送任何命令。甚至可能提供一种方法来保存选定的命令并在以后检索和插入它们——现在你有了宏工具。
如果机器人往往特别暴躁（经常失去通信、响应缓慢），那么您可能希望在用于创建命令和查看当前值的控件旁边有这个日志表。应设置控件以使用户清楚地创建离散命令。使用古怪的计算机到机器人接口，虚假命令代价高昂，因此每个命令都应该经过精心计划和深思熟虑。这可能意味着一组字段控件，例如用于设置各种属性值的文本框和下拉列表，以及为这些值生成命令的按钮。尴尬，是的，但这是与机器人通信链接的准确表示。
或者，如果队列通常几乎是空的，那么您可能希望在单独的窗口中提供此表，以便专家解决机器人行为问题。通常，用户会使用我上面给出的其他两个选项之一。