KiwiDrive HouseBot
Contents |
Log
[2011-07-05] New section, quick update: this project is NOT dead. The robot IS working. It CAN be controlled over the Internet. The user queueing system IS in place. All IS well. BUT - we don't have an internet connection because the the fibre installation was delayed... significantly. Once that is up, motivation WILL return. We are also waiting for awesome 8Ah batteries after which we will build a docking (or rather loading/unloading/charger) station. THEN my good friends, you will be driving this 'lil guy around (for 5 minutes at a time). Also, my camera got stolen - hence the lack of pictures.
Participants
- STG (Design, most parts, construction, streaming server/client)
- Linde (Motion code, construction)
- Jimbo (Motors, construction)
- Phrst (Drivers, wlan, construction, cross-platform compatibility)
- Omni (Linux system setup, construction)
- Moza (Helping hands, laser cutting)
- tilljoel (Web-based video streaming)
- qzio (Master of Interwebs)
- Quinn (Helping hands)
- JonasB (Helping hands)
- virtuald (Helping hands)
Forks
- Olleolleolle (Second build of system, update: perhaps not?)
- mansadler, stg (KiwiRay GameBot system)
Introduction
As we move to a new location, what better way to celebrate/mourn than to take on a new project?
We're building a housebot!
Once the project began design stage we realized that focusing on making it easy for others to reproduce was a good idea. Therefore we choose to use nothing but standard components. Nema 23 stepper motors and drivers are standard, cheap and common due to the increase in DIY CNC and Reprap manufacturing. The Arduino Uno is available across the world. We also only use metric standard components (sorry about that US) such as M5 threaded rods and M4, M3 screws for the smaller components.
Omnidirection wheels however are not exactly standard components, but given the simplicity of the drive mechanism it would be very easy to adapt the design for other wheels and shafts of a similar size. We have also made sure it is easy to re-design the drawings to account for other types of motors and bearings and we've left significant space (length-wise) for larger motors and gearboxes.
Although we did run into a few bumps during the first build (all of which have been solved) I believe we have managed to prove that this project can very well be completed over a dedicated weekend, given that parts have been pre-purchased.
As soon as the first trial build KiwiRay1 is completed, all plans and code will go open source, so check back here until then!
Let's go online!
One of the main objectives from the start is wa make the robot publically available on the internet. This means that anyone will eventually be able to log onto the robot and control it by remote. This required some specialized software and after surfing the interwaves for a good while we realized that to be able to do what we want, with the latency we need, we would have to go for technologies simalar to those used in gaming as opposed to traditional streaming technologies. In fact, some of the methods we use are similar to the dark magic that recently begun to allow players to play high-resolution games being run on a remote server instead of the local machine - although we do it on a much, much smaller scale.
After reading the "Diary Of An x264 Developer" article on "The best low-latency video streaming platform in the world" we started implementing a streaming/control server using the x264 library and settings discussed in this article. To enable very low latency streaming, several x264 technologies needed to be implemented:
- Slice-based threading - allows multithreaded encoding of a single frame without any frame buffering. The normal threading model introduces one frame of latency per thread.
- Single-frame VBV support - allows us to cap the size of each outgoing packet (frame) to a specific size. Artifacts introduced by capping are corrected in subsequent frames. Capping I-frames like this would destroy the stream, but...
- Periodic Intra-Refresh - removes all I-frames in favour of refreshing only small portions of the frame by means of sliding a "refresh-column" across the image in periodic intervals.
These technologies, in combination with lossy UDP datagram communications, allows us to fetch an image, encode it, receive it on the other end and finally decode it without any latency other than the CPU time required for the process and the network latency, both of which we can't really do anything about. In practice we get below 100mS on a good connection, most of which is internal latency in the webcam we are using (read: better webcam, lower latency).
On the receiving end we use FFMPEG H.264 decoding to produce the final image, which is rendered by SDL.
The streaming solution was dubbed RoboCortex and is today completely abstracted from KiwiRay and our choice of communications. KiwiRay and IPv4 UDP is implemented under RoboCortex using plugins.
This means that RoboCortex can now be easily adapted for any kind of video feedback remote control applications such as omnidirectional robots, cars, helicopters, etc. provided they are capable of encoding and transferring video at the desired bitrate and resolution. A variety of multi-user multi-protocol implementations, as well as single-user direct connections can be easily developed using the new plugin interface.
RoboCortex is open-source and cross-platform for Windows and Linux.
Source code
- RoboCortex
RoboCortex is slowly developing into a generalised robot control application, and now has a plugin system that abstracts KiwiRay from RoboCortex.
The repository also contains the kiwi-drive + I²C expansion bus sketch for the Arduino (Uno), used on the KiwiRay.
Project status
Project is currently in deployment stage (we are waiting for a stable internet connection)
Coverage (videos, pictures, articles)
- Telepresence presentation using KiwiRay base @Flickr:dcuartielles
- Test Drive #23 @YouTube:forskningsavd
- Test Drive #2 @YouTube:storerestore
- Test Drive #1 @YouTube:senseitg
- Playing DOOM I E1M1 @Bambuser:forskningsavd
- MIDI Stepper Organ @Bambuser:forskningsavd
- Build Timelapse @YouTube:senseitg
- Build picture @Flickr:jonasb
- Article @Hackaday
- Presentation @YouTube:medeatv
Design
Current Designs
This is the kiwiray platform - a NEMA23 kiwidrive designed by Forskningsavdelningen to be printed in any 4mm material using laser, water, plasma, cnc-routing or lots of patience and manual labor. It will be the base for our KiwiRay1 house-bot and it has mounts for a charging dock+webcam(+gripper?) module as well as a top platform that (in our case) will house the brains - a micro itx pc. It is powered by three NEMA23 motors and the electronics consist of three general purpose stepper drivers, and an Arduino Uno to coordinate motion and provide an I²C-based expansion bus.
Parts (Alpha Five)
Kiwidrive platform parts
-
3x NEMA 23 stepper motors
JB CNC & Linear Components -
3x Suitable stepper drivers
Watterott electronic -
6x Ball bearings 6x12x4 (IDxODxL)
Kullager-grossisten -
2x 4" Omni-Directional Wheel (2-pack)
VEX robotics -
1x Drive Shaft 12" (4-pack)
VEX robotics -
1x Arduino Uno
Electrokit -
2x Batteries -
18x M4 18mm screws -
36x M4 washers -
18x M4 nuts
Front module parts
-
1x TowerPro SG90 servo
DealExtreme -
1x Any orb-style webcam
Logitech -
2x M2 8mm screws -
2x M2 nuts -
4x M4 16mm screws -
4x M4 nuts
- 1x Plexiglass parts kit
-
4m M5 threaded rod, cut as follows:- 12x 86mm
- 12x 76mm
- 12x 96mm
- 1x 110mm
- 3x 20mm
-
89x M5 nuts -
89x M5 washers
Computer platform
-
INTEL D510MO
Dustin home -
M1-ATX 90W (PSU)
Mini ITX -
Memory -
Flash drive -
WIFI dongle
Previous Designs
|
Alpha One |
Alpha Two |
Alpha Three |
|
Alpha Four |
||
BOM
| 4m | M5 threaded rod | SEK 79,60 |
| 100x | M5 nut | SEK 39,90 |
| 100x | M5 washer | SEK 24,90 |
| 4x | Omni-directional wheel | USD 49,98 |
| 12" | 1/8" Square axle | USD 8,96 |
| 8x | Ball bearings | SEK 71,68 |
| 10x | Axle stoppers | SEK 74,00 |
| 3x | Stepper motor drivers | EUR 54,93 |
| 3x | Stepper motors | SEK 787,50 |
| 1x | Servo | USD 4,73 |
| 1x | Arduino Uno | SEK 259,00 |