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.
1. Background
These articles describe how to interface PS3 and Wiimote game controllers directly onto the Arduino using the USB Host Shield. These controllers have not previously been directly connected to an Arduino due to the USB and Bluetooth interfaces and protocols used, and their relative complexity. The game controllers are a good match to the capabilities of the Arduino, and to the imagination of Arduino users, they have not only buttons and joysticks, but also motion sensing, and other goodies which deserve to be in the hands and ideas of Arduino users. Also I hope these articles provide some guidance for people to develop other USB host and Bluetooth applications for small embedded processors.
Arduino already comes in versions which have USB and Bluetooth interfaces, but these are not suitable for our chosen game controllers. When used in USB mode, the PS3 controller is a USB device and needs to talk to a USB host. The normal Arduino USB interface is also a device, so not compatible. When in Bluetooth mode, both of these game controllers use the Bluetooth HID protocol and this is not compatible with the commonly used Bluetooth modules which support only the RFCOMM Serial Port Protocol. Arduino users have successfully used a PC as an intermediary between the game controllers and the Arduino, so the PC is host to both devices.
These articles were written by Richard who is new to the Arduino, blogs, github, libraries, etc, so please give me any help and feedback on how I might improve or correct these articles and software.
PS3 controller connected to Arduino USB Host Shield
Another HID example has been added to Github repository of USB Host Shield for Arduino (which you can purchase in my store) . Richard Ibbotson sent me this nice piece of code along with some pictures. He also posted a short description of his sketch in comments section:
I wrote a sketch for the interface of the PS3 controller over USB. I have two controllers, one Sony and one Madcatz wireless with a USB dongle. Both of these work fine to the USB host shield. I only made one minor change to the library to increase the NAK count. The sketch tests all the function, buttons, joysticks, accelerometer/gyro, leds and rumble. This is not yet under bluetooth just USB. I can set the host bluetooth adddress on the controller though which is needed for bluetooth pairing.
Did not make much attempt to reduce code or data size, so only have about 4K of program space and 240 bytes of data space left, but sketch is pretty long. The actual PS3 part is very small and could be made to a small library.
Next is to move to the bluetooth part, from what I have found on the direct USB, I am pretty confident this will fit even on the 168.
PS3 controller support opens some very interesting possibilities. Not only can it be used as a normal “joystick plus buttons” type of control, but you can also utilize it’s accelerometer/gyro. With wireless variant of the controller all kinds of very powerful radio control are possible. Who is going to be the first to make a mechanical dog, which follows you around and brings back the controller when you throw it away?
If you want to try the sketch, make sure you have the latest library code as well – there are some small but important changes made recently in NAK handling.
MadCatz wireless controller to USB Host Shield
Wireless mini keyboard connected to USB Host Shield
Here is an interesting project which uses MAX3421E breakout board to connect XBox360 wireless controller to old Nintendo Entertainment System. Francois Gervais used Cortex-M3 as an interface between Nintendo and a game controller. There are two other videos showing the details of the setup – check them out as well.
I am continuing on topic of using USB Host shield to drive USB peripherals started in the previous article. The code presented here performs keyboard polls, character translation and management of “LOCK” keys – NumLock, CAPSlock and ScrollLock.
A keyboard is hard to use if results of typing can’t bee seen, so my first step was to add an output device. Even though HD44780-compatible character LCD can be driven with Arduino pins, I wrote a little library which uses GPOUT port of MAX3421E for LCD control. This library is now a part of USB Host Shield repo on github. I used LCD high-level routines from official Arduino distro and developed low-level functions specific to MAX3421E hardware, as well as LCD initialization. Since function syntax and behaviour (and source code ) is identical to official LCD functions, the user manual is already written and can be found in the library reference by title LiquidCrystal. The only difference is in the constructor; since only 4-bit mode is possible and only one pinout is supported, Max_LCD constructor is not accepting any parameters. The pinout of LCD connections to GPOUT is given in the Max_LCD.h file; see also title image of this article.
