Building a Physical Model for Testing Your Code

The Value of a Physical Model

With most development projects there is usually a little tension between the fabrication team wanting working software to test the the hardware during assembly, and the development team wanting known good hardware for use during development. There are many ways to address this tension and strike a balance. 

My approach of choice is the use of a Physical Model that has functional inputs and outputs similar to those of the unit under development. The goal is create a test board that will allow you to work with an analog of your system's target hardware while you are writing the system's software. 

For a PC based test system, the Physical Model may be a as simple as a bank of switches and LEDs combined with a few voltage displays and a few channels of adjustable power outputs that all connect to the PC's data acquisition system. Systems involving motion control get a little more complicated.

Here is an overview of a Physical Model I built to allow me to validate the electrical design and test the firmware for a proof-of-concept device for a patented process of producing subcutaneous, or plastic surgeons' sutures. The physical model provided a hardware platform for testing the firmware to ensure proper operation before the hardware for the demonstration model was available. Waiting to test on the actual hardware would have made it difficult, if not impossible to meet the client's timeline. 

I used a laser cutter me to quickly layout and cut a panel that would house all of the needed elements and even provide engraved labels. The system below included three DC servo motors with drivers controlled via an RS-485 network. 

The client is a small startup that has multiple patents for automated subcutaneous sutures and needed a hand-held model that could demonstrate the process to potential customers and investors. I worked with them in their earliest efforts which gave me a head start on designing a the proof of concept device to help them move forward.

My assignment was to help with the electrical design and firmware to demonstrate a proof of concept of the clients patented process for automating the application of subcutaneous sutures, or plastic surgeon's sutures. The goal is a works like device to be built into a looks like hand held model. My contribution was electrical design and firmware development while the client was responsible for the physical construction and final assembly of the device.

The client had an aggressive schedule based on demonstrations that they were working on scheduling and an upcoming trade show. As is most often the case, the key to success was using as many off-the-shelf parts as possible.

I knew that the hardware assembly timeline was likely to slip and that I would have little if any access to the final assembly prior to their deadline. So I decided to build my own Physical Model to allow me to test the firmware on a target platform that would simulate all of the electron mechanical parts of the final system.

Why Product Design is Challenging

One of the earliest lessons I learned about designing automated test systems is that the hardware people want working software to test the hardware during the build and the software people want working hardware to test the software during development. There are two components needed to address this chicken and the egg problem.

First, you need a way to exercise all of the inputs and outputs of the data acquisition and control system so the hardware team can test their wiring during assembly. If you are using National Instruments hardware, then you can use their set up panels that allow you set all of the outputs and read all of the inputs of the data acquisition hardware. Still we would often have the programmer start with a minimal framework that exercises all of the system inputs and outputs and displays the status on screen. Writing this software was a great way for the programmer to get comfortable with configuring the hardware without needing to address the functional and user interface aspects of the system under development.

The second component in this solution was building a Physical Model that simulated all of the system IO to allow the programmer to test the functionality of their software against the model during development. Typically this was a panel with LEDs and switches for the digital IO and potentiometers voltage displays for the analog components.

Assembling All of the Pieces

Being an early stage, proof of concept design, I wanted the client to be able to modify and update their control sequence without needing to come back to me with each small change. Using off the shelf hardware at every possible step is the key to successful prototyping. 

I selected SparkFun's Arduino Pro Mini as the control device based on the ease of use of the Arduino IDE (to allow the client to make their own adjustments to the motion sequence target positions) and the small form factor.

I implemented the command sequence as a two dimensional array of data points that would allow the client to modify target position and motor speed settings by simply modifying the array and downloading the new firmware via the Arduino IDE. They could even add or remove steps of the motion sequence by adding or deleting rows from the array.

The system also included several machine safety interlocks that would prevent a data error from physically crashing the servo motor actuators. 

Another useful feature was a serial output that logged the system status enabling the client to see exactly what was going on inside the device. The data reporting was exceedingly useful for determining if a motion sequent stopped because a motion safety was triggered, or if the actuator was unable to reach the target position or if the system stopped due to an over current or under voltage condition. 

The design included three Maxon brushed DC servo motors with high-resolution encoders, controlled by AllMotion EZSV10  DC Servo Motion Controllers. The EZSV10 controllers communicate using RS-485 to configure the motor driver settings, receive position command and to read encoder outputs. The EZSV10 Servo Controllers pack an amazing amount of performance into a tiny package. I highly recommend their quick start kit if you want to jump into brushed DC motor servo control.

http://www.allmotion.com/Servo_Pages/EZSV10Kitdescription.htm

The initial design was powered from a single lithium ion 18650 battery with the servo motor rail voltage being produced by a Pololu U3V50F12 DC-DC Step-Up Regulator.

https://www.pololu.com/product/2568

The next iteration of the design transitioned to an external 12V source. The single 18650 battery had plenty of capacity for the application but could not power the system continuously for extended test session. Catching voltage droop during high-current moves was essential to ensure adequate power to the motors.

Custom Maxon brushed DC servo motors were selected for the final application. But the price and lead time on the Maxon motors motivated me to find alternative DC brushed servo motors for my Physical Model. I found the Faulhaber gearhead motors below on eBay with quick shipping and a reasonable price.

This configuration allowed me to test the actuator and limit switches for all three servo motors. I did need to address the differences in the encoder resolution between the Faulhaber gear-head motors and the Maxon motors. I added a jumper to my test board that the firmware checked at start up. If the jumper is found when the firmware boots up, then the software scales the motion target values to match the low resolution encoders on the Faulhaber's. If the jumper is not found, the firmware uses the high resolution target values for the Maxon motors.

The flexibility of laser cutting really stood out when it came to needing a way to test the homing switches and verify the motors were reaching the desired target positions during the sequence. Below is one of the actuators that I drew up and cut on the laser. The bump actuates the limit switch used for homing the motor and the scale is customized for each axis. Note the mounting hole was also laser cut to match the motor output gear tooth profile with a friction fit. 

For example, in the image above the highest tick mark is much greater than 360 degrees. This is to allow me to simulate an actuator that requires multiple  motor rotations while using less than one rotation on my physical model. Otherwise I need a way to keep track of which actuation is the correct actuation of the home switch. The hand-held demonstration model actually includes two limit switches, one triggered every rotation at the same point and a second that closes opens after the first revolution (the two switches were wired in an AND configuration to create a single home position indicator).

The Physical Model was indespeinvible for functional validation of the firmware during development, allowing me to meet the aggressive development schedule. Additionally, when the client requested operational changes, the Physical Model provided a way for me to validate firmware modifications at my workbench before sending updates to the client. 

I hope this has been informative and will help you develop a physical model to support your firmware project.