Compact Computer-on-Module

ADLINKThe cExpress-HL computer-on-module (COM) utilizes an Intel Core processor (formerly known as Haswell-ULT) to provide a compact, high-performance COM solution. The cExpress-HL is well suited for embedded systems in medical, digital signage, gaming, video conferencing, and industrial automation that require a high-performance CPU and graphics, but are constrained by size or thermal management requirements.

The cExpress-HL features a mobile 4th Generation Intel Core i7/i5/i3 processor at 1.7 to 3.3 GHz with Intel HD Graphics 5000 (GT3). The COM delivers high graphics performance while still keeping thermal design power (TDP) below 15 W. Intel’s system-on-chip (SoC) solution has a small footprint that enables it to fit onto the 95 mm × 95 mm COM.0 R2.0 Type 6. The COM provides rich I/O and wide-bandwidth data throughput, including three independent displays (two DDI channels and one LVDS), four PCIe x1 or one PCIe x4 (Gen2), four SATA 6 Gb/s, two USB 3.0 ports, and six USB 2.0 ports.

The cExpress-HL is equipped with ADLINK’s Smart Embedded Management Agent (SEMA), which includes a watchdog timer, temperature and other board information monitoring, and fail-safe BIOS support. SEMA enables users to monitor and manage stand-alone, connected, or remote systems through a cloud-based interface.
Contact ADLINK for pricing.

ADLINK Technology, Inc.
www.adlinktech.com

Serial Carrier Card with Flexible I/O and Serial Technology

New 3U CompactPCI Serial Carrier Card from MEN Micro IntegratesThe G204 is a 3U CompactPCI Serial carrier card with an M-Module slot that combines fast CompactPCI Serial technology with flexible I/O options. The card serves as the basis for powerful 19″-based system solutions for transportation and industrial applications (e.g., data acquisition, process control, automation and vehicle control, robotics or instrumentation).

M-Modules are modular I/O extensions for industrial computers (e.g., embedded systems and high-end workstations). The M-Module slot enables users to interchange more than 30 I/O functions within a system. The M-Module, which needs only one CompactPCI Serial slot, is screwed tightly onto the G204 and does not require a separately mounted transition panel.

The G204 modular mezzanine card operates in a –40°C to 85°C extended temperature range for harsh environments and costs $483.

MEN Micro Inc.
www.menmicro.com

High-Speed Laser Range Finder Board with IMU

Integrated

The NavRanger-OEM

The NavRanger-OEM combines a 20,000 samples per second laser range finder with a nine-axis inertial measurement unit (IMU) on a single 3“ × 6“ (7.7 × 15.3 cm) circuit board. The board features I/O resources and processing capability for application-specific control solutions.

The NavRanger‘s laser range finder measures the time of flight of a short light pulse from an IR laser. The time to digital converter has a 65-ps resolution (i.e., approximately 1 cm). The Class 1M laser has a 10-ns pulse width, a 0.8 mW average power, and a 9° × 25° divergence without optics. The detector comprises an avalanche photo diode with a two-point variable-gain amplifier and variable threshold digitizer. These features enable a 10-cm × 10-cm piece of white paper to be detected at 30 m with a laser collimator and 25-mm receiver optics.

The range finder includes I/O to build a robot or scan a solution. The wide range 9-to-28-V input supply voltage enables operation in 12- and 24-V battery environments. The NavRanger‘s IMU is an InvenSense nine-axis MPU-9150, which combines an accelerometer, a gyroscope, and a magnetometer on one chip. A 32-bit Freescale ColdFire MCF52255 microcontroller provides the processing the power and additional I/O. USB and CAN buses provide the board’s high-speed interfaces. The board also has connectors and power to mount a Digi International XBee wireless module and a TTL GPS.

The board comes with embedded software and a client application that runs on a Windows PC or Mac OS X. It also includes modifiable source code for the embedded and client applications. The NavRanger-OEM costs $495.

Integrated Knowledge Systems, Inc.
www.iknowsystems.com

Turn Your Android Device into an Application Tool

A few years ago, the Android Open Accessory initiative was announced with the aim of making it easier for hardware manufacturers to create accessories that work with every Android device. Future Technology Devices International (FTDI) joined the initiative and last year introduced the FTD311D multi-interface Android host IC. The goal was to enable engineers and designers to make effective use of tablets and smartphones with the Android OS, according to Circuit Cellar columnist Jeff Bachiochi.

The FTD311D “provides an instant bridge from an Android USB port(B) to peripheral hardware over general purpose input-out (GPIO), UART, PWM, I2C Master, SPI Slave, or SPI Master interfaces,” Bachiochi says.

In the magazine’s December issue Bachiochi takes a comprehensive look at the USB Android host IC and how it works. By the end of his article, readers will have learned quite a bit about how to use FTDI’s apps and the FT311D chip to turn an Android device into their own I/0 tool.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Bachiochi used the SPI Master demo to read key presses and set LED states on this SPI slave 16-key touch panel.

Here is how Bachiochi describes the FT311D and its advantages:

The FT311D is a full-speed USB host targeted at providing access to peripheral hardware from a USB port on an Android device. While an Android device can be a USB host, many are mobile devices with limited power. For now, these On-The-Go (OTG) ports will be USB devices only (i.e., they can only connect to a USB host as a USB device).

Since the USB host is responsible for supplying power to a USB peripheral device, it would be bad design practice to enable a USB peripheral to drain an Android mobile device’s energy. Consequently, the FT311D takes on the task of USB host, eliminating any draw on the Android device’s battery.

All Android devices from V3.1 (Honeycomb) support the Android Open Accessory Mode (AOAM). The AOAM is the complete reverse of the conventional USB interconnect. This game-changing approach to attaching peripherals enables three key advantages. First, there is no need to develop special drivers for the hardware; second, it is unnecessary to root devices to alter permissions for loading drivers; and third, the peripheral provides the power to use the port, which ensures the mobile device battery is not quickly drained by the external hardware being attached.

Since the FT311D handles the entire USB host protocol, USB-specific firmware programming isn’t required. As the host, the FT311D must inquire whether the connected device supports the AOAM. If so, it will operate as an Open Accessory Mode device with one USB BULK IN endpoint and one USB BULK OUT endpoint (as well as the control endpoint.) This interface will be a full-speed (12-Mbps) USB enabling data transfer in and out.

The AOAM USB host has a set of string descriptors the Android OS is capable of reading. These strings are (user) associated with an Android OS application. The Android then uses these strings to automatically start the application when the hardware is connected. The FT311D is configured for one of its multiple interfaces via configuration inputs at power-up. Each configuration will supply the Android device with a unique set of string descriptors, therefore enabling different applications to run, depending on its setup.

The FT311D’s configuration determines whether each application will have access to several user interface APIs that are specific to each configuration.

The article goes on to examine the various interfaces in detail and to describe a number of demo projects, including a multimeter.

Many of Bachiochi's projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Many of Bachiochi’s projects use printable ASCII text commands and replies. This enables a serial terminal to become a handy user I/O device. This current probe circuit outputs its measurements in ASCII-printable text.

Multimeters are great tools. They have portability that enables them to be brought to wherever a measurement must be made. An Android device has this same ability. Since applications can be written for these devices, they make a great portable application tool. Until the AOAM’s release, there was no way for these devices to be connected to any external circuitry and used as an effective tool.

I think FTDI has bridged this gap nicely. It provided a great interface chip that can be added to any circuit that will enable an Android device to serve as an effective user I/O device. I’ve used the chip to quickly interface with some technology to discover its potential or just test its abilities. But I’m sure you are already thinking about the other potential uses for this connection.

Bachiochi is curious to hear from readers about their own ideas.

If you think the AOAM has future potential, but you want to know what’s involved with writing Android applications for a specific purpose, send me an e-mail and I’ll add this to my list of future projects!

You can e-mail Bachiochi at jeff.bachiochi@imaginethatnow.com or post your comment here.

 

A Love of Teaching, a Lifetime of Robotics: An Interview with John Blankenship

John Blankenship

John Blankenship

John Blankenship has spent decades teaching robotics—and written many books on the subject. His love of teaching inspired him to co-develop the RobotBASIC robot programming language. I recently caught up with John to discuss some highlights from his teaching career and what’s next for RobotBASIC—Nan Price, Associate Editor

 NAN: How did you become interested in robotics?

JOHN: As a child, I often saw robots on television but was fully aware that there were no computers capable of making such fictional creations a reality. In the 1970s, microprocessors such as Intel’s 8080 and MOS Technology’s 6502 gave me hope that real robots would eventually become part of our future.

I found I could motivate my students by linking lab projects to robotic topics. For example, instead of just graphing the output from an active filter, I had my students use op-amps to detect an ultrasonic wave so they could later build a ranging sensor. I firmly believe that if you want to motivate students, you must give them projects with a purpose.

 NAN: You spent more than 30 years teaching programming, electronics, and robotics. What did you gain from that experience?

 JOHN: I enjoyed teaching electronics, but I loved teaching programming. Nothing else even comes close to develop critical thinking skills in students. Watching those skills develop was the reason I taught.

After seeing how my hardware robotic projects motivated students, I knew I wanted something similar for my programming classes. Eventually I developed a library of C routines that simulated a simple on-screen robot. What made the simulated robot special is that it supported numerous sensors (an electronic compass, two levels of proximity sensors, a ranging sensor, line detection, beacon detection, color tracking, and more) that enabled students to solve relatively complex, real-world robotics problems without building any hardware.

This structure made programming fun because it gave programming assignments a purpose. Students no longer had to be convinced that it was important to learn the syntax for a loop or how “if” statements controlled flow to make decisions—they wanted to learn details so they could use them to solve the exciting problems being proposed for them. Which would you find more exciting: writing a program to count the number of words in a string or teaching a robot to follow a line? Better yet, imagine motivating students by having a contest to see whose robot could follow a line the fastest.

NAN: How and why did you develop the RobotBASIC programming language?

MINOLTA DIGITAL CAMERA

RobotBASIC can control real robots just as easily as the simulation.

 JOHN: When I retired from teaching I wanted a way for other teachers to utilize a simulated robot to motivate their students. I could have just published my C libraries, but that generally would have limited their use to college classes where C is usually taught. I felt strongly that much younger students needed to be introduced to programming so they could develop not just logical thought, but also an appreciation for math and engineering.

I love the C language (RobotBASIC is written in C), but in my opinion, it is far too cryptic to be used as a first language. I wanted to encase my routines in a BASIC-like language that would enable nearly anyone to program a simulated robot.

I began writing my own language and was reasonably pleased with the initial efforts. I demonstrated the program to a good friend of mine, Samuel Mishal, who is easily the greatest programmer I have ever known. After politely applauding my efforts, he showed me an interpreter he had been working on to help him with a DSP project. His language was very polished and far superior to my work. He integrated my simulator with his interpreter and we named it RobotBASIC.

Even though we planned from start to freely distribute RobotBASIC, we knew teachers could not devote time to learning a language that was just a robot simulator. We began adding new features and capabilities. The more we added, the more excited we became. We started testing the new language by developing robotic behaviors and writing simple video games. Every time we needed something special, we added it to the language.

Figure3

RobotBASIC has all the commands necessary to write simple video games.

RobotBASIC currently has nearly 900 commands and functions—far more than most languages. More importantly though, since there are built-in functions to handle many things programmers normally have to do themselves, the language is very fast for an interpreter.

We felt RobotBASIC was an ideal language for introducing high school students to programming, but we wanted more. We added hardware I/O capabilities and created a wireless protocol that enabled RobotBASIC to control real robots with the same programs that control the simulation. At that point, the language could easily handle college-level projects but we knew the BASIC stigma would be a problem. To help with this, we added the option to use a modified C-style syntax, making it easier for students to transition to C or even Java.

Figure4

This simulation shows the effects of friction on a spring’s movement.

We also decided to address some backward capability by adding legacy-style I/O commands, making it easy to teach basic programming skills to even fifth graders. This enables school systems to utilize RobotBASIC from lower grades through high school without having to teach a new environment when new capabilities are needed. And if the C-style syntax is introduced in the upper grades, students will be better prepared for college programming courses.

 NAN: What are some uses for RobotBASIC?

JOHN: Even though students’ needs were a driving force in our development process, RobotBASIC’s I/O capabilities make it a great language for hobbyists involved with robotics or other electronic-oriented projects. For example, it only takes a few lines of code to gather data from a remote temperature sensor using a wireless link and to transmit that information to another user over the Internet.

RobotBASIC also has many commands that facilitate flicker-free animation and simulation. This means teachers have the option of motivating students by teaching how to write simple video games.

As much as I love the robot simulator, I have to admit that many students get even more excited about animation than they do about robots. The point is that RobotBASIC provides many options.

Figure2

The simulated robot can be programmed to solve a maze.

 NAN: You offer several types of RobotBASIC seminars geared toward children, university students, and robot clubs. You also lead seminars introducing programming and robotics. What do you enjoy most about teaching? What do attendees gain from your seminars?

 JOHN: I love teaching and I especially love showing teachers new ways to motivate their students. I understand that every school and teacher is different and I make sure I satisfy their goals by customizing each and every presentation based on their individual needs. I am always amazed that schools can’t believe that RobotBASIC is totally free. There are no acquisition costs, no upgrade fees, and no licenses—ever! RobotBASIC is free for hobbyists too. Circuit Cellar readers can download a copy from RobotBASIC.org.

 NAN: Are you currently working on or planning any robotics-related projects?

Figure6

The speed and flight path of these darts is controlled with finger movements on a tablet’s touchscreen.

JOHN: Many RobotBASIC users have been asking for a more advanced book on animation and video games. Unfortunately, my work on our new RobotBASIC Robot Operating System (On a Chip) has been monopolizing all my time for the last couple of years. Now that it is finally finished, I have started writing again.  I think the new book will be worth the wait because it also discusses how RobotBASIC can interact with the new Windows 8 sensors (e.g., cameras, compass, accelerometer, touchscreen, etc.) The chapter I am currently working on enables darts to be thrown using finger movements on a tablet’s touchscreen.

NAN: Do you have any advice for Circuit Cellar readers who are considering building their own autonomous robots?

 JOHN: I think the biggest mistake most robot hobbyists make is they spend far too much time constructing a robot before having a detailed understanding of its sensory needs and the algorithms necessary to accomplish their goals. If they would test their ideas first with our simulator, they would have the information necessary to build a platform that can actually meet their needs. Furthermore, they could control their real robot with the very same programs they developed on the simulator.