This guide gives an overview of the control software, the robot behavior, Skype integration, and guidelines to keep the robot up and running. If handled correctly the robot is capable of autonomous operation for weeks at a time, but to keep the robot healthy it must be carefully monitored and used on a near daily basis. Left unattended over a weekend and the robot will likely die (refer to the Problems section for details)
Robot Controller
The TPRobot program is actually two applications in one. One instance runs on the Asus netbook and functions as the Create and PowerPod controller and listens for commands from the control computer, and another instance runs on the control computer and sends commands over the Internet to the first instance. These two aspects of the application or depicted visually as a tab control. The first tab is called "Local Connect" and embodies the robot interface. It has settings to interface the Create, the PowerPod, and to create a command listener.
- iRobot Serial Port - The COM port number for interfacing with the iRobot Create
- Tracker Pod - Enables attachment and control of the Eagletron PowerPod.
- Allow Network Control - Enables a network command listener. Connections and commands are sent through the Skype network.
- Password - Skype authenticates which accounts are able to connect and issued commands to TPRobot and all Skype traffic is encrypted. However, for additional security this password is also used to authenticate the connecting peer.
- Attach - Attempts to connect to the Create and PowerPod. Once connected the robot will be in "drive" mode and the battery will not be charging - even when it is sitting on the charger.
- Detach - Disconnects from the Create and PowerPod and puts the Create into charging mode. You must detach the robot to charge the battery.
The second tab - called the "Skype Connect" tab is used to configure the remote controller. All communication between the two applications is sent via the Skype network. Skype is primarily thought of as a VOIP app, but it is also a generic communication platform that can be leveraged to send messages between external applications. The Skype application serves as a proxy, setting up the connection and handling the data transmission. The bandwidth is not terribly high but for an application like this it is more than adequate. The benefit is that Skype handles all the messy details of connectivity, firewall traversal, encryption, and message reconstruction for you.
- Skype ID - The Skype ID of the account being used on the netbook. Separate accounts and ID's should be used for the netbook and control computer.
- Password - This should match the password configured on the netbook.
- Connect - Creates an authenticated Skype connection to the robot controller. Upon successful connection the screen will be turned on and the robot will be automatically "attached" and drive mode initiated.
- Disconnect - Closes the connection to the robot controller. The robot interface is "detached" and the charge mode is initiated. To reduce the power draw on the battery while in charge mode the robot screen is also turned off.
The driving controls are all keyboard based using a layout familiar to gamers.
- Move Forward - W
- Move Backward - S
- Turn Left - A
- Turn Right - D
- Up-Shift - Space
- Look Up - Up Arrow OR NumPad 5
- Look Down - Down Arrow OR NumPad 8
- Look Left - Left Arrow OR NumPad 4
- Look Right - Right Arrow OR NumPad 6
- Look Straight - NumPad 7
IMPORTANT: The TPRobot window must maintain keyboard focus for the controls to operate properly. If you click on a different window while driving, the robot may continue moving even after you release the keys. Click back on the TPRobot window to regain control again.
The right hand controls the PowerPod. Each tap of the arrow keys or number pad will rotate the head a few degrees. In practice, head movement is not used very often. I usually just drive with the left and keep my hand on the mouse - only stopping to adjust the head if I bump into something or to talk to a person that is standing. Even then I typically only use the look up and look down controls because looking right and left is functionally the same as turning right and left.
The bottom half of the UI displays the robot speed and sensor status.
- Speed - The text displays the independent speed of each wheel, while the progress indicator shows the total forward or backward speed of the robot. The digit to the right of the progress indicator shows the current gear.
- Dock - Turns orange when the robot is within proximity (about 8 feet) and facing towards the charging base. Turns green when the robot has successfully docked and has electrical contact with the charging base.
- Auto Dock - The button becomes enabled when the charger base proximity light is on. Clicking it initiates the auto-dock function - during which time all drive controls are disabled and the robot will automatically enter a search pattern and attempt to dock with the charge base and start the charging cycle. The auto dock feature is very imprecise and will often take 2 or 3 attempts before correctly docking. It is best to line up the robot manually before selecting Auto Dock.
- Bump - Turns red when the robot hits an obstacle and the front bumper is activated. The robot will immediately stop all forward momentum when a bump is detected. There are no bump sensors for the rear or sides of the robot.
- Error - Turns red if a software exception occurs on the robot controller.
- Battery - Displays battery capacity and usage data. The text indicates the actual voltage and current draw detected on the battery. The progress indicator gives an "estimate" of the amount of battery capacity left. The progress indicator is not always accurate - especially when the robot is sitting on the charger. After a few minutes of usage the progress indicator becomes more accurately calibrated.
To customize the robot functionality, the robot controller can execute batch file scripts. Any batch files found in the \run\scripts folder will be made available under the "File->Run Scripts" menu. Scripts located on the robot controller can be executed by the control computer. Just about anything can be performed by the scripts, but the two useful examples provided in the release are RestartComputer.bat and RefreshWireless.bat the purpose of which should be obvious.
The robot has some major flaws. I have explored them a bit and - so far have not come up with permanent solutions. However, I have discovered ways to work around these problems and have come to terms with them. Once you learn to manage these issues the robot can be operated with very little outside help for weeks at at time. Still it is a good idea to have someone at the office that is well acquainted with the robot and its flaws to help you out when necessary.
Updated Solutions 10/11/2011-> Part 9: Upgraded Power Management
1. Charging
The biggest problems with the robot have to do with the battery draining. On a full charge the robot can operate for over an hour making short drives and video conferencing. That is ample time to talk to people and then get back to the charger. The problems start at the charger. When the iRobot Create docks with the charger it enters into its charge cycle and the battery light will start slowly blinking red. During this time the netbook is still on and drawing power, but the battery is still able to charge up. Once the battery becomes fully charged the Create will then show a solid green light and enter into a trickle charge state that is designed to keep the battery full. A flaw in the Create firmware prevents it from taking into account the current draw of the netbook however, and it never notices that the netbook is slowly draining the battery. It fails to reenter the charge state and it continues to show a green light for several hours while it drains away until - poof ! The battery and the netbook die.
There is no way to put the netbook into a low power "sleep" state because it must be ready at all times to accept control requests. The Asus motherboard does not support "wake on wireless LAN", so it cannot be put to sleep. The only way around the problem is to continually send a "reboot" command to the Create so that it will recheck the battery and restart the charge cycle. (Luckily there is an undocumented command 7 that handles this). So the TPRobot application must connect to the robot once every hour to send a reboot command and keep the battery charged. Great! - but that will only keep it alive for about 2 days straight. Even with this "hack" in place the Create somehow slowly loses track of the correct battery charge level, and the only way to recalibrate it is to take it off the charger and drive it around for a few seconds. After recalibration it can then be placed back on the charger and the process can start all over again. So at a minimum you MUST connect to the robot every one or two days and drive it around for a few moments - even on the weekends. Following this procedure I have been able to keep the robot operating continuously for a month. So that's not so bad -- except in conjunction with the next flaw.
2. Serial-USB Disconnect
This problem is more difficult to diagnose. Sometimes when the Create is getting back on the charger it momentarily drops its hardware connection to the netbook. This happens fairly frequently - maybe one out of every five times that it docks. As a result the TPRobot application loses all contact with the Create and is not able to reconnect to it without throwing an error. (Unauthorized Access Exception). Without the ability to communicate with the Create, the TPRobot is unable to send the reboot commands and so - again the robot battery will drain within a few hours. There are two ways to fix this. First - if a person physically unplugs and replugs the Create USB cable into the netbook, then the TPRobot application will be able to reestablish a connection. However if a person is not available then the only other way to fix it remotely is to reboot the netbook. So the second procedure the operator must follow is to notice whenever the TPRobot loses contact with the Create and send a Windows reboot command. This capability has been built into the software to simplify this task.
3. Docking power loss.
Similar to the above problem and a relatively new but serious problem. I only experienced it after 3 months of operation after replacing my Create robot with a new one. Sometimes during docking (presumably on the transition between non-charging and charging) the Create will drop all power to the netbook and the netbook will instantly turn off. I have yet to understand this problem but it does not bode well for the overall design. It may have been a mistake to remove the battery from the netbook - at least with the battery, these brown outs would not be catastrophic.
4. PowerPod Craziness
Another difficult problem. Once every week or two I will lose complete control of the PowerPod when attempting to rotate it. I don't know if it's a transient power issue or software bugs in the drivers, but whatever happens is catastrophic. The PowerPod will just suddenly rotate to maximum on both axis (look up at ceiling) and the motors will stay engaged trying to rotate even further. Attempting to rotate it back has inconsistent results. Often it will just move all to way in another direction. The only way to fix it seems to be to "detach" the TPRobot interface, unplug the USB cable on the back of the PowerPod, and physically force it back into home position. Then reconnect the USB and try to gain control again. This may have to be done one or more times before the hardware and drivers finally synchronize. I don't really have not investigated this problem very much so I cannot really say whether it is a fault with the hardware integration, the Eagletron driver software, or the TPRobot software.
Next-> Part 9: Upgraded Power Management