This is the status update on Arduino USB Host Mini development, announced 3 weeks ago. I received rev.0 PCBs last Saturday – BatchPCB is faster than ever! I made a test build (see title picture) and after fixing one major and several minor mistakes placed an order for what I’m hoping will be the final pre-production sample.
The prototype was built to sit on top of Arduino Pro Mini to make access to the parts easier during troubleshooting. On the final board USB connector is placed slightly further away from the pins; it will be possible to place Arduino on top of the shield so that the height of the “sandwich” will be less or equal to the height of USB connector.
In 2-3 weeks I’m hoping to finalize the design and start producing the USB Host Mini. Stay tuned!
Many people asked me to post a video showing an arm from inverse kinematics article in action. While making a video, I realized that shots of the arm following a pattern of computer-generated coordinates is going to be less than exciting and decided to add manual control. The video below shows the result. In addition to the video, a HID introductory page has been written describing HID communication basics as well as some simple Arduino code. Enjoy! ( Youtube link, where HD quality video can be selected ).
This post announces starting of development of new Arduino USB Host Shield variant. There are several projects in the works (thanks, guys for letting me know!), where standard size Arduino board is too big. Since electronics of USB Host Shield is pretty simple, it was decided to shrink the board as much as possible. Here is the first iteration.
The initial revision of USB Host Shield in Mini form factor is shown on title picture, It is intended to be used with Sparkfun’s 3.3V Arduino Pro Mini. Intended applications include digital camera control devices, robots, as well as any other projects where size and weight has to be minimized. The Gerbers was sent to BatchPCB; I’m expecting boards back in couple of weeks. The main goals of this first prototype are manufacturability check as well as checking claims made below.
The Mini Host is simplified version of full-sized shield; only USB and GPIO are available. By default, VBUS is routed to VCC, therefore only self-powered USB devices are expected to function (even though I have at least one USB flash drive which works fine powered from 3.3V VBUS). I also provided extra pads to simplify signal re-routing, however, since there was no place left for jumpers a trace has to be cut instead. The same has been arranged for VBUS – if 5V power is necessary, Arduino Pro Mini/Shield combination can be powered with 5V on RAW pin, the VCC trace cut off VBUS and RAW and VBUS connected.
As soon as first prototype is tested, I will post CAD files and also make boards available at BatchPCB. Stay tuned!
Blue Arduino USB Host Shield tied to telephoto lens mount
Developer Si Li shared his version of PTPDevinfo.pde, which fits into older Aduinos. Si wanted to get PTP device information from Canon EOS 500D, but he only has 16K Seeduino at hand. So he stripped devinfoparser off all unnecessary strings leaving only ones essential for parsing Canon EOS camera device info.
I’m proud owner of Lynxmotion AL5D robotic arm. The parts kit is of very high quality, and as a result, the arm is very strong and versatile. I wanted my arm to be portable and independent of big computers and all currently available controllers lack flexibility that I needed, therefore I started building my own controller around Arduino platform. This article shows first preliminary result of this work – inverse kinematics code which would be used to position the arm.
In robotics, inverse kinematics is a method to position a tip of some linked stricture in 3D space by calculating joint angles from tip X, Y, and Z coordinates. Much information about the subject exists on the web, for example, this introductory article explains the subject using simple trigonometry.
To move the arm, six servos need to be controlled ( five for the arm without wrist rotate ). Given that large amount of processing time would be spent calculating servo angles, I decided not to drive servos directly from Arduino pins and made simple servo shield using Renbotics schematic and library code. I built only half of the circuit using single 4017 counter – this gives me seven servo control channels, which is plenty.
In addition to the article linked above, I’d like to mention two other resources, which helped me tremendously during code development. First is Micromega Application Note 44, which shows inverse kinematics equations for similar arm. They also have nice video of working arm. It should be noted that gripper of AL5D arm has much simpler geometry, therefore second order polynomial calculations are not necessary. The second one is this Lynxmotion project page with Excel spreadsheet. Many formulas from the spreadsheet were used in my code; I also used the spreadsheet during debugging after modifying arm dimensions.
Below is first working draft of inverse kinematics code. It can be used as-is or transformed into a library. As presented, it shall be used with caution – no boundary check is performed so it is quite easy to inadvertently send the arm flying into your forehead or the control board. The code uses single-precision floating point math, which seems to be adequate for the task.
I found this little video while looking for ideas for my digital camera controller. There is also project description and summary page. Device consists of Arduino board mated with Asynclabs WiShield controlling shutter release of SLR camera via cable release port. Arduino runs TCP/IP stack and Web server while access to pre-focus, time interval and other settings is done via web browser on an iPod. In addition, it is possible to release shutter using signal from proximity sensor or even set conditions based on states of different Arduino pins.
The web interface is well designed – watch this little movie and see it for yourself. There is also a demo page, where you can play with controller functions. The “Adm” page is my favourite. I’m looking forward to see the code, which author is going to publish soon.
Quadrature rotary encoders, also known as rotary pulse generators, are popular input devices for embedded platforms, including Arduino. Several rotary encoder code examples are posted on Arduino site and elsewhere, however, they treat encoder as a pair of switches, adding decoding/debouncing overhead. For many years, I used an algorithm based on the fact that quadrature encoder is a Gray code generator and if treated as such, can be read reliably in 3 straight step without need for debouncing. As a result, the code I’m using is very fast and simple, works very well with cheap low-quality encoders, but is somewhat cryptic and difficult to understand. Soon after posting one of my projects where I used rotary encoder to set motor speed i started receiving e-mails asking to explain the code. This article is a summary of my replies – I’m presenting small example written for the purpose of illustrating my method. I’m also going through the code highlighting important parts.
The hardware setup can be seen on title picture. The encoder from Sparkfun is connected to a vintage Atmega168-based Arduino Pro. Common pin of the encoder is connected to ground, pins A and B are connected to pins 14 and 15, AKA Analog pins 0 and 1, configured as digital inputs. We also need a serial connection to the PC to receive power, program the Arduino, and send program output to the terminal. For this purpose, Sparkfun FTDI basic breakout is used.
Connecting encoder pins to pins 0 and 1 of 8-bit MCU port makes encoder reading code very simple. If analog pins are needed for something else, it is possible to move encoder to digital pins 8,9 or 0,1 (losing serial port) with no modification of code logic. While technically using any two consecutive port pins is possible with a bit of tweaking, using non-consecutive pins for encoder input with this method is not recommended. Lastly, it sometimes hard to determine which encoder pin is A and which is B; it is easier to connect them at random and if direction is wrong, swap the pins.
I’m starting new series of articles describing exciting field of digital camera control. In modern cameras, USB port can be used not only for transferring images to a PC, but also for sending control commands to the camera. It is often possible to send commands which “press” the shutter button, modify shutter and aperture values, some cameras are even capable of doing focus control. At the same time, new shooting techniques, such as HDR and stacked focus, require that a photographer makes several shots, slightly modifying one or several shooting parameters from shot to shot. Even age-old time lapse technique could use some automation. Since camera manufacturers are, as always slow to implement there cool features, Arduino comes to the rescue.
I am announcing new code developed for Arduino USB Host shield which implements digital camera control functions via PTP. Alex Glushchenko, a developer from my native Russia, recently joined camera control project and code shown here and in the future articles is mainly his. He did most of reverse engineering and code development and my contributions to this project were mainly code testing, camera borrowing, and blogging. Code is hosted on github separately from USB Host library. Be warned – this source is preliminary and will be changed many times before it becomes stable! It is also expected to grow quite a bit – different cameras use different commands and developing universal code supporting all manufacturers (or even every camera from one manufacturer) is not possible due to the modest resources of Arduino platform. Therefore, several libraries have been developed, each covering specific set of cameras. The cameras supporting functions of a certain library are listed in library’s header file. The list of cameras is currently quite small but I’m hoping to get more cameras supported in the future.
Digital camera as USB peripheral is much more complex and less standard than a keyboard. The complexity starts at the very first level – device configuration. Very often , several different configurations are supported on a device and the default configuration is not the one we need. Therefore, the first step would naturally be learning how to recognize configuration which supports camera control commands.
There are 3 specifications describing USB digital camera works. Still Image Device specifies USB requests, descriptors and endpoints. The protocol structure is described in Media Transfer Protocol (MTP), which is better known by its previous name, “Picture Transfer Protocol” (PTP). The most interesting document, which actually lists commands supported by camera class, is known as “PIMA 15740-2000″. It is available for a fee from I3A, however, second-hand pdf copy can be obtained for free after some googling. Camera manufacturers implement their own functions, expanding PIMA definitions. In addition to that, some older cameras use their proprietary protocols instead of PTP; support for such cameras will be added eventually.
This is the third part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:
Part 3. Develop the Bluetooth USB and HCI interface used in the support of the Wiimote and PS3 game controller, and also some utilities needed to analyse and configure these devices.
1. USB Interface
As before, we first look at the descriptors for the USB dongle using the USB_Desc sketch. The result is:
This is the second part of a series of articles written to describe development of interface between Arduino and popular game controllers using USB Host Shield. Previous parts:
Part 2: Develop the USB interface to the PS3 controller
1. USB Reduced Hosts
Full USB hosts such as Windows and Linux based computers can manage a large variety of different USB devices and load appropriate USB drivers for each device. There is an enumeration or discovery phase where the host gathers information on the attached USB device and uses this information for the driver selection and configuration. In small embedded applications this is not possible or required to support this variety, so the application usually only supports a few devices, often only one. This means the discovery process can be much reduced since the results are already known. This will reduce the memory required for the application by hard coding the device configuration into the application.
Though the configuration will be hard coded, we still need to initially gather the information from the device itself and other sources.
The existing device drivers mentioned above for Windows and Linux are important in our development process. The Windows drivers are usually complete, but not available in source form. Linux drivers are available in source form, though not always as complete. Device manufacturers are usually very reluctant to provide information required to build a driver or embedded application. So we rely on copying Linux code or “sniffing” Windows code to give us guidance.
