Article first published at:
I’ve been struggling to think of a good project to start on. I’m currently writing the APNIC Box series here, and I’m on part 4 of maybe 7 or 8 right now. I like to keep at least one personal project of interest on the go at a time so back to struggling for inspiration.. Feel free to tell me that this is an awful idea and suggest something else, but until I hear otherwise I’m going to roll with it.
Linux Robot – Requirements
Here’s what I’m thinking. Small embedded device, way smaller than the Mikrotik 532a used for the APNIC Box. The board will need USB [as we’re going to use the 5v for charging later]. I’d like to start with a powerful enough board that it can be expanded later with relative ease.
The device will initially have few inputs and outputs. It will support miniPCI, USB, Serial Console, CF card, GPIO or some other good method for controlling a relay board and some motors. The device will have 4 small wheels, maybe rubber [old mouse] balls instead and some ultrasonic sensors, 4, 6 or 8.
The hardware will be flexible enough for really powerful software control. The OS running on the device will of course be Linux, and will have the ‘robot software’ loaded onto the CF card. The device will accept USB ‘programs’ to be uploaded and downloaded. These programs will have full access to the sensors, wheel relays, LEDs, battery information, etc.
I’d like to power the device by a reasonably small and light 4.2v? battery, it will accept charge from a 5v USB source.
The USB source will be mounted in some kind of housing that the device can very easily and clumsily fit in to. Both the USB source device/charger and the robot itself will contain a radio [definitely 802.11g later], but for now a simple FM oscillator would probably be good. The software will also have access to this radio. The device will maintain contact with it’s base station. IR won’t be any good here as the device needs some kind of a range. I’ll need to assess the practicality of range vs hardware.
The key initial wow factor will be the fact that the device upon reaching a certain battery charge threshold will seek out and return to its base for automatic charging.
The device will need some kind of cache – it’s last 100 actions where an ‘action’ might be 100msec of wheel movement. Should the device lose its base station, it should attempt to start reversing those actions until it reaches the base station. It will also require some basic common sense as to roughly how it got to wherever it’s sitting so it can reverse on it to locate the base station rather than aimlessly getting lost.
One of the important aims of the device is that it’s capabilities are only realistically limited by the software instructions we upload to it, and not it’s hardware.
I would like the hardware to at minimum be capable of expanding to more advanced hardware, such as the wifi mentioned above, maybe an IR transmitter, etc, etc. As we all know once the hardware is set up and we have a solid OS on board, the possibilities are endless.
I’ve found a few similar projects out there:
These projects look great but don’t really seem to address what I want to build here. I’d really be interested to know of any similar project or resources already out there.
I’ve scattered some initial ideas down here and would really welcome for some feedback on this. The first step is going to be to lay out some more solid ideas and milestones and then start sourcing a board. I’m also going to have to build schematics and hardware prototype boards for portions of it and interfaces between the various child boards in side.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- RSS Feeds
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Weechat, Irssi's Little Brother
- Senior Perl Developer
- Technical Support Rep
- UX Designer
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?