I rented a TeleMe robot for attending a computer conference in San Francisco, from the UK, primarily as an experiment to determine the utility of this tech. Here is feedback on how that went.
Using a robot for remote attendance actually works quite well for randomly meeting people and attending sessions. However there were some serious problems with the hardware and software used in this case which greatly limited its effectiveness and my autonomy. Most of these things could be much improved with better preparation and the right options fitted.
The robot used in this case was a Mantarobot TeleMe with a Samsung Galaxy Tab head unit. The device was manufactured by Mantarobot and rented from Telepresence Robots (in Roxborough Colorado). This machine was chosen because it was a) available, b) linux compatible and c) inexpensive.
For the control channel both WebRTC and Mantaro Communication Server were used. For the comms channel both google hangouts and Skype were tried. We didn't get time to try other possibilities like Jitsi. Note that the comms channel (to the head unit) and the control channel (to the base unit) are entirely separate.
I got a lot of help with this experiment. So much thanks to Leif Lindholm and Riku Voipio as primary local helpers, with extra help for various others at various times. Also to Jerry at Mantarobot for enabling MCS when WebRTC failed, and Jeff Mills at Telepresence Robots for very helpful pre-sales service.
1) Audio out is much too quiet. It's fine for talking to one person close up in front, but nothing more. This made it useless in areas with lots of people around, or trying to communicate with a presentation going on. To speak in a session, someone needs to hold up
a mic for you.
Add-on bluetooth speakers are available which would fix this issue.
I get no volume control - people locally have to work that. So one can't 'speak up' (this could possibly be worked-around with remote screen access).
Skype leaves my laptop mic on so typing comes out loudly at the robot end. This is annoying in a quiet environement (and of course you can't tell until someone complains).
2) Video quite low-res, but mostly adequate. It's not even close to good enough for reading slides. If slides are not available on-line one has no idea what is being shown. Recognising people at a distance can be a bit tricky.
The camera is not really wide angle enough so one gets slightly tunnel-vision and need to keep moving the head to see who's talking. The Mataro controller UI has a handy feature for setting direction to look in, which can be moved to with single key. Useful to keep moving head between 3 or 4 people in a meetings.
Ability to see who is talking is major improvement over listening to an audio-only stream.
3) The mic is quite sensitive but it was still quite hard to hear in some sessions. Auto Level Control worked quite well, and echo-cancellation was excellent. Hard to tell to what degree this is the mic or the hangout/skype low-bandwidth audio. Hangouts seemed to be worse than skype.
4) I was unable to connect autonomously to the comms channel, so had to have local help every time. Combined with very regular connection dropping, this was a _major_ problem. Hangouts never ran for more than 40 mins without crashing. Skype once stayed up for 2hrs, but mostly it was much less.
For hangouts someone had to 'answer' the call every time, but that did connect both audi and video.
With Skype it could be set to autoconnect, but that only connected audio. A local user had to turn video on every time.
Because of this one is not actually autonomous at all. Without an external channel (IRC) and local helpers it would really not have worked.
5) Wifi connection dropping.
This was actually the biggest problem. The control channel dropped out 3 times on day1. 3rd time the base had to be power cycled before I could reconnect.
Hangouts dropped out 5 times in the day. Someone has to be around to 'answer' the call and reconnect me.
It became clear during the week that wifi handover moving down the corridor from the hackrooms (where the charger was) to the conf rooms was not reliable, so one was quite likely to lose either comms (so can't see to drive) or control (so can't move). Either is
'fatal'. This is a known issue and this machine can be supplied with a 2nd wifi card so that it can do such handovers reliably, but we didn't have that model.
6) Control channel issues
Apart from dropouts things worked quite well on day1, but come day2 the WebRTC control channel simply wouldn't work at all. I was unable to connect. It is not clear why this stopped working (possibly due to network changes by IT to fix something else?).
We got back up and running when support at Mantarobot enabled me to use their 'MCS' (for free, it's normally a paid service).
MCS worked much more reliably than WebRTC, and I used it for the rest of the week.
7) Connection quality
This was mostly fine, but could randomly get poor. e.g. once it worked fine for a whole session, then when I tried to talk to someone at the end it became terrible, with chopped up speech and the comms channel dropping out several times, before we just gave up. Just like a bad mobile line. Very hard to know if this is network traffic, the tablet, my computer, or some issue with hangouts/skype
The Mantarobot was quite easy to control (nice UI) after a short period of getting the hang of it. And I was able to practice beforehand via a test robot in the Mantarobot office, which was useful.
However at full speed the rented machine had a strong tendency to steer to the right so one had to compensate. Combined with some visual latency this could be tricky. It would be much better if it went in a straight line when asked.
Moving around hackrooms with lots of chairs and tables was difficult. One had to pan the head down so see exactly where a chair was, and doorways needed a bit of practice due to the 'tunnel vision' making them seem closer than they really are. Floor wiring is not hard to negotiate but does make the robot rock quite hard. A permanent auxiliiary down-pointing camera would be much nice to use than panning the one tablet camera up and down. Some other robot models have this (I see why now :-).
The robot is quite slow, annoyingly so for someone walking with you. My compatriots had to wait for me quite a lot, and after a while worked out that the easiest thing to do was pick up my bot and just carry it wherever we were headed. The Mantarobot is quite light so this is easy. They also did this when I got stuck in the corridor due to wifi dropout.
9) Battery life
Battery was adequate, but not enough to do a whole day, if one moved around more that to one sessions and back. It worked fine for standing around for 3 hours in one place. In practice it lasted half a day. I only got stranded once. The bot can connect to its own charger with a bit of careful driving. But that was in the hackrooms, so the gauntlet
of the 'corridor dropout' had to be run to return and charge.
The limited battery life discourages one from just wandering about or trying to go to to many different sessions.
The UI shows the base battery status, but not the tablet batterystatus. I have no idea of that. I can remotely disconnect the tabletfrom the base to save base power, but have no feedback to know if this is a good idea or not.
10) Physical Limitations
The bot cannot open doors or use lifts, or negotiate stairs, so itonly works if the conf is all on one level, or there are ramps. And if you are late for a session then you can't get in until someone comes and opens the door for you.
This conference was all on one level, but that is not always the case. Some thought on how to get remote control of lifts (or a local 'finger') would be needed to make this a general solution, or at least having ramps between levels. To some degree this is a general 'disability access' issue, although many disabled people can work lift
There is no way to raise a hand in a session in order to speak. Perhaps the screen could be made to flash to attract attention?
Someone has to be responsible for assembling the machine, setting up the charger, getting the machine to connect to local wifi, then disassembling/repacking it at the end and sorting out return shipping. It would be best if this was done by the conference team
along with the rest of the setup/teardown. For this first test this was done by Leif, with me doing return shipping admin (which is a pain to do remotely).
Because it is not set up until the conf is started, one has little time to sort out any issues with connecting eith control or comms channels (see issues below). Again, if this was a normal part of conf setup one could check the day before.
The time offset is a bit of an issue. It's OK to be in the UK for a west-coast US conference, but because 6pm there is 2am local time one if not very enthused about going to the bar in the evening, because its bedtime. Given hardware that could cope with the noise level I might have stayed up to try it.
So in summary I think this concept has potential. It worked well for person-person comsn in quiet rooms or area, but not for conference chat. The right hardware, software, connectivity and service backup is needed for it to work well in a conference situation