Five golden rules for prototyping robotic systems

Five golden rules for prototyping robotic systems

Rules aid in the design of a quadrotor autonomous helicopter

BY BEN BLACK and SHELLEY GRETLEIN
National Instruments
Austin, TX
http://www.ni.com

A well-thought-out plan for prototyping can significantly pay off in the long run and can be even more important in robotics applications than in other fields, because typically robots move and interact with people, which can lead to difficult or dangerous situations. We share here some lessons learned while designing a quadrotor autonomous robotic helicopter.

A working robotics prototype involves mechanical, electrical, and software design and may be used as a proof-of-concept for your customer, as a marketing or sales tool, or just to provide a first attempt at proving an idea. Keeping the following five rules in mind will help you quickly move from the prototype to the next step of the design process.

1. Ideas are cheap

Generating ideas and potential designs has no inherent cost other than your time, so why not spend a little extra time thinking through the prototype before starting on the more costly physical, electrical, and software design? The process begins with brainstorming, research, more brainstorming, and some pencil and paper design, and then progresses to picking a design path and moving forward.

At this point, the goal should be to gather just enough information to converge on a solid design without getting overly bogged down in the details. You want to do enough research to prevent reinvention of the wheel, but also to remain focused on moving to the next stages. For us, a commercial product inspired the quadrotor robotic helicopter design; however, it quickly became obvious that a large research and hobbyist community exists, providing some great resources. After a week of scouring forum posts, academic research pages, and electronic versions of students’ theses, a basic design emerged a design which eventually became the robot shown in Fig. 1 .

Fig. 1. The current prototype: the fully autonomous quadrotor robotic system designed with NI LabVIEW and Single-Board RIO controller.

2. The 80-20 rule

Frequently, the devil is in the details of a prototype. In physically generating a working piece of robotics hardware, 80% of the total work gets finished in 20% of the total time required to finish the project. Remember that the goal of a prototype design should be to make it to the “good-enough” level. You should be careful to not get caught up in the final details of polishing the design that can indefinitely extend the project timeline.

The physical and electronic designs of the quadrotor helicopter use off-the-shelf hardware and software components where possible. Instead of using a sophisticated carbon fiber frame that would require a custom mold and an autoclave, we used easy-to-find carbon fiber tubes attached to a simple aluminum base. Similarly, the motors, propellers, and motor control electronics came from the hobbyists’ community and can be mounted easily.

3. Plan ahead for the ‘creep’

Invariably the design of the prototype will change as the project begins to mature. The potential customer might have suggestions, the information collected during the research phase might not have covered all of the potential pitfalls, or the algorithms might need more sensors to function properly. You must be ready for potential new requirements by having a flexible software and hardware design. The quadrotor helicopter is built around a National Instruments Single-Board RIO controller that has a real-time processor, an FPGA, and hardware for analog and digital I/O.

This flexible hardware choice, along with a suite of NI LabVIEW software we used, enabled us to handle changing requirements. For example, the NI Single-Board RIO controller originally looked like it might be overkill for the stability control algorithms; however, as the design progressed, some components of the advanced control scheme needed to be moved into the FPGA to increase performance and stability.

What was originally overkill was actually needed, and the flexibility of LabVIEW for FPGA design made the movement of the control component nearly transparent. With traditional development tools, I would have had to rewrite my embedded C code into a hardware description language (HDL), which is not a trivial task. With LabVIEW, we were simply able to move the graphical icons from my real-time processor to the FPGA device and recompile.

One of the only custom-built components of the helicopter plugs into the NI Single-Board RIO and provides an interface between the pins of the controller and the sensors and actuators. A close-up of this daughter board can be seen in Fig. 2 .

Fig. 2. A daughter board provides easy connection from the NI Single-Board RIO controller to the sensors and actuators.

The original design of the helicopter only needed four digital outputs and six analog inputs; however, the board layout has extra headers for both analog and digital I/O. It turned out that the original design had no way to measure the system battery voltage. By using one of the extra analog input connectors, we were able to update the hardware quickly without having to wait for another board to be built.

4. Design for reuse

To overly simplify, the single goal of a prototype is to move to the next phase of the design process, whether that next step involves production or another more refined revision. A designer has to ask, “What part of the system can be reused in the next phase?” and focus any extra effort on those reusable parts. In the quadrotor, the controller and the daughter board can be reused as well as nearly every piece of the software.

The design of the quadrotor helicopter’s control algorithm began with a relatively complicated software model and a robust simulation of the closed-loop control system. A crash of the controller could easily cause serious hardware damage, so the controller needs to be tested and tuned in a simulated environment.

The flexibility of the LabVIEW Control Design and Simulation Module allows the full simulation to be built with the same blocks that then become reused in the real-time control system. The simulation shown in Fig. 3 becomes control software by replacing the simulated plant with calls to the physical I/O hardware. LabVIEW provides software modularity by presenting the functionality in graphical blocks of code that are easy to reuse and intuitive to use.

Fig. 3. LabVIEW was used for both the graphical simulation of the control algorithms and the implementation of the real-time and FPGA hardware.

5. Don’t focus on cost

Design engineers often spend a lot of time up front optimizing the cost of a final product that will likely change significantly during the building of the prototype. While cost should factor into development and seriously impacts a prototype’s ability to become a viable product, an engineer can get overly caught up in this optimization cycle and waste valuable development time.

The quadrotor helicopter design uses previously tested off-the-shelf components for Bluetooth communication hardware and for five axes of a six axis inertial measurement system. Both of these components could be designed into the daughter card using similar less expensive technology. However, instead of spending the engineering effort on those components, extra time was spent on the control algorithm development, allowing the use of a more advanced and more stable controller. ■