我正在编写一个需要从XBox 360控制器获取输入的程序.输入将以无线方式发送到我正在建造的RC直升机上.
到目前为止,我已经了解到这可以使用DirectX的XInput库或XNA中的Input框架来完成.
我想知道是否还有其他选择.我的程序范围相当小,并且必须安装像DirectX或XNA这样的大型游戏库似乎过多.此外,我希望该程序是跨平台的,而不是微软特定的.
有一种简单的轻量级方法,我可以用像Python这样的东西来获取控制器输入吗？
编辑以回答一些评论:
直升机总共有6个螺旋桨,分布在3个同轴对中.基本上,它将与此非常相似,只需花费约1,000美元而不是15,000美元.它将使用Arduino进行板载处理,使用Zigbee进行无线控制.
选择360控制器是因为它设计得很好.它非常符合人体工程学,并且具有所需的所有控制输入.对于熟悉直升机控制的人来说,左操纵杆将控制集体,右控制杆控制俯仰和滚转,模拟触发器将控制偏航.模拟触发器是360控制器的一大特色.PS和大多数其他人没有它们.
我有一个项目的网页,但它仍然很稀疏.我确实计划记录整个设计,所以最终它会很有趣.
http://tricopter.googlecode.com
在旁注中,是否会杀死谷歌为googlecode项目提供博客功能？
我希望360控制器输入程序尽可能在Linux和Windows中运行.最后,我想将控制器直接连接到嵌入式微控制器板(例如Arduino),这样我就不必通过计算机,但目前它并不是一个高优先级.
我是Python的新手,我一直使用标准的cpython(v2.5)实现.
我一直在想其他实现,特别是Jython和IronPython.是什么让他们更好？是什么让他们变得更糟 还有哪些其他实现？
我想我正在寻找的是每个实现的摘要和利弊列表.
我正在尝试为我的Makefile创建一个通用的构建模板,就像他们在eval文档中讨论的那样.
我似乎无法使用通配符函数在eval中工作.我遇到问题的基本代码看起来像这样.
SRC_DIR = ./src/
PROG_NAME = test
define PROGRAM_template
$(1)_SRC_DIR = $(join $(SRC_DIR), $(1)/)
$(1)_SRC_FILES = $(wildcard $$($(1)_SRC_DIR)*.c)
endef
$(eval $(call PROGRAM_template, $(PROG_NAME)))
all:
@echo $(test_SRC_DIR)
@echo $(test_SRC_FILES)
@echo $(wildcard $(wildcard $(test_SRC_DIR)*.c)
当我用它运行make时,输出是
./src/test
[correct list of all .c files in ./src/test/]
基本上,PROGRAM_template中的通配符调用没有像我预期的那样被评估.该调用导致一个空列表.
尽管如此,正在正确评估联接调用.
那么,我做错了什么？我的猜测是
$$($(1)_SRC_DIR)
是不正确的,但我无法找到正确的方法.
编辑 一旦解决了这个问题,我花了很长时间才能用eval来解决另一个问题.我在GNU Make 3.80评估错误的解决方法中将其作为一个新问题发布
我正在建立一个简单的SQLite数据库来保存传感器读数.表格看起来像这样:
sensors
- id (pk)
- name
- description
- units
sensor_readings
- id (pk)
- sensor_id (fk to sensors)
- value (actual sensor value stored here)
- time (date/time the sensor sample was taken)
该应用程序将从大约30个不同的传感器每月捕获大约100,000个传感器读数,并且我希望尽可能长时间地将所有传感器读数保留在DB中.
大多数查询都在表单中
SELECT * FROM sensor_readings WHERE sensor_id = x AND time > y AND time < z
此查询通常会返回大约100-1000个结果.
所以问题是,在上述查询变得太耗时之前,sensor_readings表有多大(在标准PC上超过几秒钟).
我知道一个修复可能是为每个传感器创建一个单独的sensor_readings表,但如果没有必要,我想避免这种情况.有没有其他方法来优化此数据库架构？
我正在尝试为我的Makefile创建一个通用的构建模板,就像他们在eval文档中讨论的那样.
我遇到了GNU Make 3.80的已知错误.当$(eval)计算超过193个字符的行时,使用"虚拟内存耗尽"错误导致崩溃.
我的代码导致问题看起来像这样.
SRC_DIR = ./src/
PROG_NAME = test
define PROGRAM_template
$(1)_SRC_DIR = $$(SRC_DIR)$(1)/
$(1)_SRC_FILES = $$(wildcard $$($(1)_SRC_DIR)*.c)
$(1)_OBJ_FILES = $$($(1)_SRC_FILES):.c=.o)
$$($(1)_OBJ_FILES) : $$($(1)_SRC_FILES) # This is the problem line
endef
$(eval $(call PROGRAM_template,$(PROG_NAME)))
当我运行这个Makefile时,我明白了
gmake: *** virtual memory exhausted. Stop.
预期的输出是./src/test/中的所有.c文件都被编译成.o文件(通过隐式规则).
问题是$$($(1)_SRC_FILES)和$$($(1)_OBJ_FILES)长度超过193个字符(如果有足够的源文件).
我已经尝试在只有2个.c文件的目录上运行make文件,它工作正常.只有在SRC目录中有很多.c文件时才会出现错误.
我知道GNU Make 3.81修复了这个bug.不幸的是,我没有权限或能力在我正在研究的系统上安装新版本.我坚持3.80.
那么,有一些解决方法吗？也许拆分$$($(1)_SRC_FILES)并在eval中单独声明每个依赖项？