Our Robot on Live TV
This week we had the opportunity to present our robot 'ToBi' live on TV. Well, it was a great opportunity on the one hand, but on the other hand this also meant intense preparation ... again. Altogether, it was a good performance, IMHO. However, I decided to compile a few 'survival guide' essentials, you can find them below the picture. If you ever get the chance to present your robot live on TV, they will become useful at some point. Trust me, there are pitfalls! Last but not least, I assume you don't entirely script/hardcode the demo, thus you (should) demonstrate autonomous behavior — that's what robotics is all about, am I right?
I further assume you have already given a couple of demos, presentations, etc. Thus, I also imply you are familiar with the usual 'noise' in this context.
- #1 Testing, testing, testing, make sure your system works as expected wrt the core components of your demo. Make sure they have been tested thoroughly at least a couple of days before the actual event.
- #2 Gather as much information as possible about the environment in the TV studio
- #2.a How are the lighting conditions? Lots of infrared light? What about your (vision) sensors then? Much reflective material? Back light?
- #2.b If you deal with a mobile robot, is the environment problematic for your base/wheels, i.e., carpets, stair tops, stairways, drop-offs, cables, etc. Usually, you don't have these things in your lab — for a reason.
- #3 Build a 'replica' of the tv studio in your lab, at least an approximation of it. Based on my experience, (potential) show stoppers were only identified after 'replicating' the studio environment. Usually, TV stations have constructional drawings of their studios, get them if you can. Ask for pictures, ask for everything that will help you to assess the situation on site. At best, if the studio is near by, just go there and ask if you can have a look at it.
- #4 The story. Often, TV stations approach you with some kind of story they want to tell about the robot. Make sure you can deliver! If you are not 100% sure, always ask if changes can be made. For example: we were once asked if we could grasp a glass with water in it ... um NO?!
- #4.a The HRI part. If there is Human-Robot-Interaction involved, try to bring your own staff/actors or at least brief the interaction partners beforehand. To be completely honest, well designed HRI should always work for naïve users, but to minimize the risk of unforeseen behavior (which will happen at some point) just brief everyone involved in the interaction. In both cases (own staff or staff from the studio/audience), try to practice the scenario/story before the event with the actual people. On the one hand, this helps to identify bugs or glitches, which can be solved without touching any source code, on the other hand the overall scenario will look much smoother. Example: you rely on speech recognition for your demo and for some reason you need a hotword, e.g., name of the robot [robotname]. Naïve users, without any experience or briefing, tend to address the robot in a "very natural way". The exemplary scenario: ask the robot a simple question. The naïve user goes like this: "Awwww, [robotname] is so cute. Can I ask the question now? How is it called again [robotname]? Oh, okay [robotname]? ...What is the time?" Your robot will most likely answer: "I don't understand. Can you repeat the question?" and this will most probably happen at some point while the user is still speaking ;) Of course, you can solve all these situations in your code, but briefing a user in the first place is also helps a lot in order to prevent these situations in the first place.
- #5 Hardware. If you have two robots of the same kind available, bring them both. In the end, robots are fragile things and are to be handled with care which is not always assured, especially if a third party for shipping/transportation is involved. In the worst case scenario you are well prepared, every practice run was perfect, but two minutes before the show your only robot breaks for some unknown reason. It goes without saying, this also applies for peripheral devices like, routers, laptops, charging stations, cameras, lasers, etc.
- #6 Software. Well, I assume you freeze features and versions a long time before the event. However, make sure you have backups, and more importantly, have a process in place to deploy them immediately, also test this!. If you bring two robots, also make sure they have the same software version(s) (firmware, drivers, OS, etc.) installed. Switching from a broken to a working robot should be a matter of minutes, not hours.
- #6.a Software and unforeseen changes. I was talking about a 'story' earlier, well, you can define/refine/discuss the requirements and the story line as detailed as possible, but usually the stage direction makes last minute changes. Trust me they will! Sometimes it is just one word or sentence the robot must say differently, or an initial pose that is just 50 cm away from the original spot. Be prepared for this case. If you need to touch like 10 files and recompile stuff, this will most likely not work in time. I know that this is an issue that can not be resolved in a generalizable way and is also heavily dependent on your infrastructure/architecture and tools. However, keep this in mind when you design your system for these kind of events. Often, it also helps to have some kind of 'Wizard-of-Oz' GUI that interacts with your system and allows to skip/pause/stop behaviors or states. This GUI should also have a TTS feature, for instance. For example: In the beginning of the show, the robot should introduce itself and the show. The stage direction decides to additionally mention a sponsor, last minute of course. Now, depending on you architecture, software components and infrastructure this might be either easy to handle for you, or in contrast, very time consuming/stressful and may result in an un-tested state machine (or something similar) ... panic mode on! Thus, a WoZ GUI is extremely helpful, just type in the desired text, execute TTS, and skip the first state of your behavior with the default text. As simple as that.
- #7 Make lists! Really, lists can be a life saver. Image the following: you manage to implement and test your scenario in time, but only just in time. Now you realize you need to pack stuff in order to ship your robot. Since you are in a hurry you pack every item because you think it is essential without keeping track. Once you arrive in the studio you realize you are one LAN cable short unfortunately it's the one you need to scp code onto your robot, you also forgot a power cable for the charging station of the robot and the robot is already down to 32%. Make lists!
I hope this helps. If you have additional advice, drop me a line and I will include it. Cheers.