• View
• Edit
• History
• Print

Battery

Question:Experiment with Packet Group 3. Can you set up an experiment (script) that records the battery state as the battery discharges? Try setting up some type of experiment that will run for about 15 minutes that will allow you to monitor the power use of the Create using RealTerm. Note that RealTerm has the ability to save its screen data to a file. Can you plot some of this data in excel and draw some meaningful conclusions?

1. How is the battery affected when using Drive Direct: ChandniS

2. How is the battery affected using LEDs: LisaB

3. How is the battery affected using songs: LisaP

4. Results of drive command on battery utilization: ChrisM

5. How does weight affect battery usage: MichaelH

6. How does wheel usage during drive direct affect the battery charge: ThinhV

Name: Chandni Sanariya Blue Cohort

How Battery is Affected using Drive Direct

Purpose/Description of Lab:
The purpose of this lab is to determine the changes in the battery sensor packets using different commands, or in my case, drive direct.

I went about doing this by writing out a script to send the robot: 128 131 152 10 145 254 212 255 206 155 200 142 3 153 Then 153 to play the script. The script basically tells the robot to go -300 mm/s right wheel velocity, -50 mm/s left wheel velocity and every 20 seconds it will send back the sensor reading from packet 3 (batteries). This basically has the robot going backwards towards the right. So I translated the data that I recieved into decimal numbers and graphed them.

Results/Conclusions: Looking at the chart, you notice that the battery temperature decreases gradually, dropping only 6 degrees celsius in 15 minutes. I also noticed that the battery capacity stayed constant throughout the entire 15 minutes. I also saw that the battery charge decreased pretty consistently with only a few mAh dropped per 20 seconds. As you can see the current was not consistent at all. It was fluctuating throughout the 15 minutes and jumped around alot. Like the battery charge vs. time, the voltage decreases consistently also. It wasn't fluctuation like the current and it barely dropped 1 volt through the 15 minutes.

This is the actual file if you would like to see it. It might open as OpenOffice or Microsoft Excel.

To see other Battery Results go to Battery & Power Sensors on the CreateBase.

Name: Lisa Baumoel Blue cohort

Question: Experiment with Packet Group 3. Can you set up an experiment (script) that records the battery state as the battery discharges? Try setting up some type of experiment that will run for about 15 minutes that will allow you to monitor the power use of the Create using RealTerm. Note that RealTerm has the ability to save its screen data to a file. Can you plot some of this data in excel and draw some meaningful conclusions?

Purpose: This experiment will be used to find out how quickly the battery state changes when using LEDs.

Hypothesis: The battery state will drain faster when the power LED is on full intensity than when it is on half intensity.

Materials: Create, RealTerm

Procedure:

Results/Data

Conclusion:

The temperature, capacity, and current remained the same throughout each individual trial. The charge and voltage decreased with time throughout the trials. The charge decreased more quickly when all the LEDs were on at full power than when advance and play were off with the power on at half intensity.

Name: Lisa Pinals, blue cohort

Objective: To experiment with sensor packet group 3 and discover how the battery discharges when the robot plays songs.

Hypothesis: The battery charge will decrease in equal increments with the same song being played repeatedly.

Materials:

• Create
• RealTerm and Computer

Procedure: I first wrote a very long song with the longest notes possible to use up the battery enough to have a visible change in 15 minutes. The song I wrote and the first command I sent through RealTerm to the Create was 128 131 140 15 15 31 255 33 255 34 255 33 255 31 255 36 255 38 255 39 255 38 255 36 255 33 255 31 255 36 255 33 255 31 255. The first two opcodes turn the Create on and on safe mode. The 140 designates song number 15 for 15 notes. The following opcodes are the note names (I used low notes in the 30's) with the time for each note (I used 255ms because it is the longest possible note length to use up enough of the battery to measure). This song unfortunately did not sound very nice. Then I sent over 152 7 142 3 141 15 155 255 153. This is a script that first receives sensor packet 3 from the sensors concerning the battery, then plays song 15 that I wrote, and finally waits for 255ms so that I had enough time to record the data coming back from the sensors. The 153 at the end allows this to script to play over and over again. Finally I sent over 153 to start the script. I recorded the data for about 15 minutes before shutting the Create off.

Data and Graphs:

Conclusion: To find how long the battery would take to be completely drained (have a battery charge of 0 milliamphours), I first calculated the slope of the battery charge line in the first graphs using my first and last data points: (25.5, 2701) and (892.5, 2656). The slope of this line is -45mAh/867sec. Then using the line form y=mx+b, I found the y intercept and finally plugged in y=0 to find out at what x value the line will cross the x axis. At this rate, the battery will not have a charge of 0 until it has been 52,058.5 (about 14.5 hours)seconds from when I first started running this script. It's doubtful the battery could really last this long even if it was just playing simple songs over and over again. The Create probably needs a battery charge alot larger than 0 to keep it running. The graph does prove my hypothesis, however, because the battery charge does decrease with equal increments with the same song being played over and over again. The battery capacity stayed constant at 2702mAh, the current vacillated consistently, and the voltage generally decreased.

Name: Chris Merrill (Red)

Purpose: To determine the function and abilities of the Create's battery-and-power-related sensors.

Here are graphs of all the data I collected, with the wheels moving at 100mm/s, no load:

Charge (blue) and Estimated Capacity (Green) in mAh vs. Time - Image.

I used the stream command to get my data, which sends packets every 15 ms. The data table for that would be too large for here, so you can download the datafile here. I used sensor packet 3, so it sends back:

[19] [a byte] [3] [Packet 3 data, 10 bytes] [Checksum byte]

The data was plotted with MATLAB, using this script file to generate the matrices. You'll have to remove the "txt" extension if you want to use it, though.

Voltage (blue, mV) and Current (Green, mAh) vs. Time - Image.

Results: As can be seen by the above graph, the estimated charge remaining for the battery is inaccurate when compared to the actual remaining charge. The charge also seems to go down at a constant rate, which is to be expected as the current (seen on the other graph) remains constant, ignoring noise, at a given current.

The voltage measurement, on the other hand, did not seem accurate at all. It followed a series of plateuas, first decreasing and then jumping back up to a higher level. Given that the current is constant, and there are no external factor affecting resistance, it is highly unlikely that the voltage would have any reason to spike that way.

The temperature sensors were giving roughly constant readings throughout the experiment, at around room temperature, so I thought it futile to include a graph of that data.

The only other data returned by packet 3 is the charging state, which for the duration of this experiment was 0, meaning normal use.

!Michael Harradon

Red Cohort

Purpose

The purpose of this experiment is to determine how a change in weight affects the battery usage of the Create. This will be based upon the current and the voltage being drawn. An increase in the weight of the Create will increase the current of the battery and decrease the voltage.

Experiment

Procedure:

1)Turn on the robot and send the op-codes 128 131 to activate the interface and put it in safe mode.

2)Send 142 3 to determine the current state of the battery.

3)Send 145 1 244 1 44 to make the robot drive in a circle.

4)Send 142 3 every minute for 15 minutes to get the state of the battery.

5)Turn off the robot and load it with 200 g of weight. Repeat steps 1 through 4.

Results

As demonstrated in the chart, the current decreased overall as the weight was increased. This seems contrary to what you would believe, but it may be the result of an increase in traction by the Create. There may also be unknown variables influencing the results, as they were performed on different robots by different people. The voltage used was also decreased by the adding of weight. This may be because it is a measure of the output of the battery and the drain of the weight caused it to lose energy more rapidly.

Comparing Battery Condition When Using Drive Direct

Name: Thinh Vu (Red Cohort)

Purpose/Description of Experiment: The purpose of this experiment was to see the difference in energy consumption when when using one wheel in drive direct or two wheels. The original hypothesis was that the usage of two wheels would have almost double the consumption of one wheel. By creating a script to measure the battery constantly, this was possible. After 128 131 was used for open interface and safe mode, a script was put in for 152 5 142 3 155 300 153. This would have the Create send back the battery state every thirty seconds. I put in 145 0 100 0 0 and allowed the entered 153 for the script to run for ten minutes. Then I recharged the robot and reentered the script for the battery measure. I put in 145 0 100 FF 9C. The two wheels ran for ten minutes in a circle. I converted the data into decimal and then graphed/charted it with Microsoft Excel.

Results/Conclusions: When comparing the raw data, it is interesting to find that the battery charge decline for both trials was fairly equal. The battery did not start out at the same place for both trials because there was human error in charging the robot. Trial 2's use of two wheels did not double the drain of trial 1's one wheel. This can be seen by comparing the slopes of the lines in the chart. However, trial 2's voltage and current was much greater than that of trial 1's. This could be explained by the further use of the motor to power one more wheel in trial 2. This shows the difference in using one or two wheels, while the actual battery charge drain was much more discreet. My hypothesis was not proven correct, and the results lead me to believe that the creators of the Create could have possibly installed some energy conservation devices within the robot. At this rate, drive direct could have been used for a very long time before the battery was completely drained whether one wheel or two wheels were used.

I captured the graphics by using Microsoft Excel and then their charting tool. Afterwards I used print screen to copy the screen and pasted it into Adobe Photoshop. With photoshop, I scaled the images and saved it as a jpg. I uploaded it onto photobucket and displayed it here. ^^

Click here for the Excel Data File With Graphs Δ

Back to CreateBase Sensors

Back to Sensors: Opcode 142 Back to CreateBase