Benchmarking the battery voltage drain in Anki Vector and Cozmo
In my previous story, I discussed how a simple program can be written to monitor Anki Vector 24x7. Many of the discussions in social media…
In my previous story, I discussed how a simple program can be written to monitor Anki Vector 24x7. Many of the discussions in social media about the story seemed centered around Vector’s battery performance. Indeed, battery life is an essential ingredient of a robot, and by extension, for Internet of Things (IoT) devices. A mobile robot needs a battery, and can be active only as long as it retains battery power. Given the high interest in how Vector’s battery performs, we thought that it was document an unbiased third party investigation. Moreover, since the Vector is representative of a full-scale industrial robot, it is a great candidate for evaluation of the current state of battery technologies in robotics. In this article, we compare the battery voltage drain rate as a function of time for two of Anki robots, the Anki Vector, first released in October 2018, and Anki Cozmo, first released in October 2016.
Lets first visit the basics of battery performance. The most common batteries used in cellphones, laptops, tablets, and other electronic gadgets are the Lithium Ion Batteries (LIBs). LIBs are popular of very high energy density and a long battery life. The high energy density lets manufacturers such as Anki pack a ton of energy in small devices such as the Vector and the Cozmo. Abu-Sharkh et al. have a great evaluation on the voltage drain behaviour of a lithium-ion battery in .
In order to evaluate and compare battery performance between two products, we need a benchmark. We designed the benchmark around common guidelines of testing battery performance, such as that documented in . The benchmark consists of the following steps:
Drives off the battery charger after making sure that the battery is in a fully charged stage.
Uses the “Drive in a Square” example program that Anki provides to simulate robot activity. In short, this program drives the robot is a square of length 20 cm, and returns to the origin after driving the square. We use a simple program to make sure that both the Cozmo and the Vector can perform the identical task.
Pauses for a time of 30 seconds between each iteration of driving a square. This pause is done mainly to simulate idle activity in robots, that is periods of time when a robot may not be doing any task; but just waiting for the next instruction.
Executes steps 2 and 3 through multiple iterations, till the battery volatge drops by 0.2 Volts.
Instructs the robot to drive back to the charger once Step 4 is complete.
The voltage at the battery is measured using the standard API commands. Unfortunately, Anki does not have any API to measure the current drawn from the battery, nor does it specify the accuracy of the voltage observed; hence we will have to live with the voltage returned by the API for this evaluation. Moreover, note that the Anki Cozmo SDK and Anki Vector SDK are two separate python packages, so there might be differences in the way a connection is maintained to the robot. We hope that such issues have very minor effects to the comparisons made and analysis provided in this article.
The measured voltage is fed to Wavefront for easy monitoring and visualization. Wavefront also allows us with a lot of tools to analyze and interpret this data. In this particular case, we compute the 15 minute moving average of the derivative of the measured battery voltage. This measure gives us a good idea of how the battery voltage drains over time.
We will release the benchmark open-source once we have cleaned up all the code. Please monitor this space for my Twitter feed for updates.
So how did Anki Vector and Cozmo perform. The following figures plot the voltage drain for Vector and Cozmo.
First, note the see saw curve in the voltage drop for Vector. The drop in voltage occurs at the times when Vector is driving in a square (Step 2). During the pause time (Step 3), the voltage rises a bit. This behavior is very consistant with Lithium ion batteries; a large draw of current causes a voltage drop; after which the voltage rises when the current draw ebbs.
Next, note that Cozmo’s battery does not exhibit the same behavior, that is, the voltage remains steady even during the pause time (Step 3). This suggests that the current drawn by Cozmo is much less than that by Vector.
Lastly, lets us compare the rate of voltage drop between the two robots. Vector’s battery drained at an average rate of 0.4 mVolts/second during the duration of the experiment. Cozmo’s battery drained at an average rate of 0.22 mVolts/second. This suggests to us that Vector’s battery typically drains at approximately 1.8X faster than that of Cozmo.
There are several key reasons behind why Vector’s battery could be draining much faster than that of Cozmo. One of the key reasons behind higher power consumption would be the Qualcomm Snapdragon processor that Vector has; which provides smartphone level compute power allowing the Vector to perform much higher autonomous computation than the Cozmo. Vector also sports much more sensors: 4 advanced microphones, multi level touch capacitative sensor, and an infrared laser scanner. Lastly, Vector has a much higher resolution multicolor display screen; which definitely draws higher current. Keith has written an excellent article documenting the differences between Anki Cozmo and Vector. Given all these goodies; I am happy to live with a 1.8x battery drain.
Hope you enjoyed reading this article. Batteries perform very different under different weather conditions, and therefore the dataset provided here is just an example.
PS: I have an online course to teach AI with the help of Vector available at: http://robotics.thinkific.com
PS: If you are interested in Vector’s battery life, you might find my evaluation of my two year old Vector’s battery interesting.
 Abu-Sharkh, S. and Doerffel, D., 2004. Rapid test and non-linear model characterisation of solid-state lithium-ion batteries. Journal of Power Sources, 130, pp.266–274.