Conference season at Quanser is a stressful but exciting time. Each year, the Engineering team is called upon to create demonstrations of our equipment. These demos showcase the key features and advantages of the Quanser approach to engineering education and research. They can range from simple operation of hardware, to more complex presentations of the possible expansion and customization of our platforms.
Over the years, I’ve had the opportunity to attend over 20 engineering conferences and trade shows, from Argentina to Russia. The majority of these events required custom demonstrations, from dancing pendulums and flying drones to video games and custom IoT smart grid concepts. But whether complex or simple, every successful demo had a few important attributes.
It Has to Work…
It doesn’t matter what the demo shows and who it is for. At the end of the day, it has to work. There are definitely times where you can side-step an issue by talking about a product without actually showing how it works, or emphasizing a functional feature while ignoring another that isn’t functional. However, for a great demo, there needs to be a demo.
Imagine you want to showcase the potential to customize a QUBE-Servo 2 system on stage in front of 300 professors. In such case, it’s critical to have backup plans upon backup plans. You need to ensure that if everything falls apart, you can pick up the pieces and instantly cobble something together.
… and It Has to Work for a Long Time
A few years ago, we gave an on-stage demonstration of the Quanser Driving Simulator. The demo was a relatively simple Simulink model and visualization connected to a Quanser Rotary Servo as a hardware-in-the-loop element.
Though the demo in an ideal world should have been as easy as running the Simulink model, I wanted to make absolutely sure that in the worst-case scenario, the demo would go on. To that end, I not only configured the demo to be launched using a single shortcut. I also made sure that it would run for hours without needing to be reset. With that, I could run the demo, test that it was working, and then leave it running until my cue. As a plan B, I also created a recording of the demo running so that I would be able to bring up a video showing the demo if need be. And this example brings me to the second critical element of a successful demo.
Plan for Complications
Embrace Murphy’s law and assume that anything that might go wrong will, and plan for an alternative. Sometimes even the simplest demo can have one or many potential “complications.” Your first instinct should be to simplify the functionality and ambition behind a demo to try to eliminate potential problems.
To address these threats, many demos that we have built over the years have been based on showing something that looks like it’s working. But behind the scenes, it was not functioning exactly as advertised. Don’t get me wrong, what we’re showing is 100 percent possible and, typically, working as intended. We merely built in fail-safe measures to ensure that we have eliminated any possible potential for it to fail.
Here is a good example. We created a demo where we wanted a camera to scan a map and locate a particular feature in a region of the image. While the system could reliably find the intended image, we programmed the system to stop over the target region whether or not the image was in fact found. That way, we eliminated the potential issues caused by particular lighting conditions in the exhibit hall.
In most cases, a demo needs to actually perform as intended so that you can speak to the functionality of the system and show the source code. But when the stakes are high, I would recommend a couple of mirrors and some smoke to prevent any complications.
Be Authentic
Despite the previous recommendation, for me, the most crucial factor in a successful demo is it’s authenticity. The demo should represent the true capabilities of a system. This ensures that the demo will live on in the minds of the audience long after they see it.
The demo should not only show what the product could possibly do. When customers choose to make a purchase, they should have access to all capabilities as advertised by the demo, no matter how ambitious and impressive it was. We don’t want our team to have to explain to customers that the demo they saw was only ever meant to be a demonstration of a possible solution, and is not actually available. We believe that showing a flashy and exciting demo that is not shippable to a customer wanting to experience the same for themselves is never worth it.
A Few More Tips
Over the years, my own experiences, as well as those of my colleagues, taught me to take a few other precautions to ensure our demos run without any hiccups:
Notifications: I always make sure that all notifications on my laptop or PC are turned off. Also, checking that your machine will not go to sleep is a good idea.
WiFi: Never rely on the exhibit hall WiFi unless absolutely necessary. Wireless systems behave totally differently, if at all, in a conference center surrounded by other tech demos.
Cables and spare parts: I have taken to carrying a bag of every cable and most hardware elements that are needed for a demo in my luggage as a backup every time I travel to a show. That’s my backup in that worst-case scenario when something doesn’t work, or some part gets lost during shipping.
All in all, I would say that creating demos has been and continues to be one of the most fulfilling aspects of my role at Quanser. And with some precautions, you can create a great demo that really engages and excites your customers.
