Robotics

Human Robot Getting Closer: iCub Robot Must Learn from Its Experiences

A robot that feels, sees and, in particular, thinks and learns like us. It still seems like science fiction, but if it's up to University of Twente (UT) researcher Frank van der Velde, it won't be. In his work he wants to implement the cognitive process of the human brain in robots. The research should lead to the arrival of the latest version of the iCub robot in Twente. This human robot (humanoid) blurs the boundaries between robot and human.

---

Decades of scientific research into cognitive psychology and the brain have given us knowledge about language, memory, motor skills and perception. We can now use that knowledge in robots, but Frank van der Velde's research goes even further. "The application of cognition in technical systems should also mean that the robot learns from its experiences and the actions it performs. A simple example: a robot that spills too much when pouring a cup of coffee can then learn how it should be done."

Possible first iCub in the Netherlands

The arrival of the iCub robot at the University of Twente should signify the next step in this research. Van der Velde submitted an application together with other UT researchers Stefano Stramigioli, Vanessa Evers, Dirk Heylen and Richard van Wezel, all active in the robotics and cognitive research. At the moment, twenty European laboratories have an iCub, which was developed in Italy (thanks to a European FP7 grant for the IIT). The Netherlands is still missing from the list. Moreover, a newer version is currently being developed, with for example haptic sensors. In February it will be announced whether the robotics club will actually bring the latest iCub to the UT. The robot costs a quarter of a million Euros and NWO (Netherlands Organisation for Scientific Research) will reimburse 75% of the costs. Then the TNO (Netherlands Organisation for Applied Scientific Research) and the universities of Groningen, Nijmegen, Delft and Eindhoven can also make use of it. Within the UT, the iCub can be deployed in different labo

ratories thanks to a special transport system.

Robot guide dog

The possibilities are endless, according to Van der Velde. "The new iCub has a skin and fingers that have a much better sense of touch and can feel strength. That makes interaction with humans much more natural. We want to ensure that this robot continues to learn and understands how people function. This research ensures, for example, that robots actually gather knowledge by focusing on certain objects or persons. In areas of application like healthcare and nursing, such robots can play an important role. A good example would be that in ten years' time you see a blind person walking with a robot guide dog."

Nano-neural circuits

A recent line of research that is in line with this profile is the development of electronic circuits that resemble a web of neurons in the human brain. Contacts have already been made to start this research in Twente. In the iCub robot, this can for example be used for the robot's visual perception. This requires a lot of relatively simple operations that must all be performed in parallel. This takes a lot of time and energy in the current systems. With electronic circuits in the form of a web of nerve cells this is much easier.

"These connections are only possible at the nanoscale, that is to say the scale at which the material is only a few atoms thick. In combination with the iCub robot, it can be investigated how the experiences of the robot are recorded in such materials and how the robot is controlled by nano-neural circuitry. The bottleneck of the existing technical systems is often the energy consumption and the size. The limits of Moore's Law, the proposition that the number of transistors in a circuit doubles every two years through technological advances, are reached. In this area we are therefore also on the verge of many new applications."

MTM Tricks & Tips

Microsoft Test Manager Tips and Tricks

Microsoft Test Manager 2010 (MTM) is a testing utility for managing and running manual and automated test cases for a TFS Team Project. It integrates really well with Visual Studio 2010 and the Visual Studio 2010 web client (http://icstfsweb). However, there are several helpful tips and tricks that can make using MTM a better overall experience. This article contains some of those helpful hints and will continue to grow as new things are discovered.The first thing that must be done to improve the MTM experience is to install Visual Studio 2010 Service Pack 1. There were some significant bug fixes and improvements to MTM that were released in SP1 due to a lot of customer complaints when it was initially released in April 2010. The Microsoft site has the full list of SP1 improvements to MTM. To install SP1, go to: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en.Installing SP1 and SP2
The Visual Studio 2010 Feature Pack 2 has a number of testing features that expand MTM including capture and playback for Silverlight 4 web applications, using action recording to fast forward through manual tests, and support for coded UI tests using Firefox. It is cumulative so FP2 includes everything in FP1. For more information about Visual Studio 2010 FP2, go to: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en.

Pausing and Resuming a Manual Test

There is a handy little trick that Microsoft did a poor job of making visible, so you may not be aware of it. When running a manual test in Test Runner, there may be a need for return to MTM while running a test (that is, to look at the Test Case details). There is a Pause button, but that will not return to MTM to view details about the Test Plan or Test Cases.

At the top of the Test Runner GUI, there is an icon that will allow you to pause the current run (even if you are creating an Action Recording). If you hover over the icon, the tooltip says, "Return to the Testing Center" (see Figure 1).

"Return to the Testing Center" icon (Figure 1).

When inside the Testing Center, you can view Test Cases, change Test Plan properties, or whatever you wish. When you want to resume the running of the manual test, click on the Return to Test Runner icon in the upper right-hand area of the Testing Center (see Figure 2). When hovering over the icon, the tooltip displays "Return to Test Runner." This icon is only visible when you have paused a manual test run.

"Return to Test Runner" icon (Figure 2).

Speeding Things Up in Test Runner

By default, a local set of Test Settings is created so you can immediately start running manual tests in Test Runner. However, the default settings may not be the best for the testing you are doing. You can go into the Lab Center and create a new set of Test Settings under theSettings tab, by clicking on the New button (see Figure 3).

Creating New Test Settings (Figure 3).

This will open up a new form where you can specify your customized Test Settings. On the first page of the New Test Settings Manager, type in a name, description (optional), and specify if these will be used for Manual Tests or Automated Tests (see Figure 4). Then click on the Nextbutton.

General Test Settings (Figure 4).

On the next page you can select the Roles that your test machine will use. Typically this would be either Desktop Client or Web Client depending the type of application you are testing. The simplest Role would be Local if you are just running manual tests on your laptop. After selecting one (or more) of the Roles, click the Next button.

The next page is where you can select and configure the Data and Diagnostics that you want to have saved off for each running Test Case. These settings can affect your performance (see Figure 5).

Data and Diagnostics Test Settings (Figure 5).

The biggest slow down can come if you have IntelliTrace turned on. Typically you would want this turned off until you have a failing test that you want to debug. In that scenario you would turn it on so you get more information to determine what the problem is.

The Video Recorder setting is a great option to turn on when you have automated tests running overnight. You can actually see what happened while your test was running (you will need Microsoft Expression Encoder installed). There is a setting in the configuration of the Video Recorder options to save videos of passing tests. It will save a lot of disk space if you deselect that option – videos of failing tests will still be saved (see Figure 6).

Configure Video Recorder (Figure 6).

Click the Next button to see the Summary page, and then click Finish. You can set these Test Settings to be used by default on all manual tests by going to the Test Plan Properties page.

Test Controller on a lab Virtual Machine

There is a trick to getting a Test Controller to work properly on a Virtual Machine (VM) in the lab. The problem is that if you are at your desk on your machine, you will not be able to send tests that you want to run to that Test Controller. It has a problem resolving the name of the machine. Even though the machine is registered and added to the TFS Collection, your machine will not be able to resolve the name. It has to do with DNS. You can do either of two things to overcome the problem (the second option is recommended).

1. You can add the IP address of the VM to your local hosts file. To do this you would find out the IP address of the VM, then go to (usually)C:\Windows\System32\drivers\etc, and then add the IP address of the VM to the hosts file.
2. The other option is to contact the lab team (Alan Keeler, Rodney Harrison, among others) and ask them to add the VM bane to the DNS on ldschurc.org. This will allow any user that has rights to see the Test Controller to send tests to it.

One last thing to remember is that you must have Test Agents registered with the Test Controller to actually run the tests. The Test Controller only does the coordination of sending out the tests to the Agents and routing the results back to the TFS database.

Video Recording

You can turn on Video Recording which will take a video of Tests that are running or even ad hoc manual testing. To make this option available, it will be required to install Microsoft Expression Encoder 4.0. This is a free download from http://www.microsoft.com/download/en/details.aspx?id=24601. The files are stored in a "Expression Encoder Screen Capture" format and saved it with a ".XESC" extension. To turn this feature on, see Figure 5 above in the Speeding Things Up in Test Runner section.

There may be some people that will want to replay the recording but don't want to install Expression Encoder. There is a way to get the minimal pieces to see the encoding by installing the codec at http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10732 and theninstalling the video data adapter.

There is one other option which is that you could open the video recording .XESC file in Microsoft Expression Encoder and save it in WMV or MP4 format. Test Runner will save the video recording file automatically to a bug when created from a failed Test Case in the default XESC format. It is possible to open the file, convert it, attach the WMV or MP4 file to the bug, and then delete the XESC file. Then anyone can replay the videos without installing anything.

Adding Special Suites

By default, the only Work Item Type (WIT) that can be added as a suite (also known as a requirement) to a Test Plan in MTM 2010 is a "User Story." If you try to add any other type of item to the Test Plan it will fail and possibly crash. The way to add more WITs as acceptable suites or requirements is to use the witadmin utility which is located in Program Files\Microsoft Visual Studio 10.0\Common7\IDE.

To see the options available to pass in on the command-line to witadmin.exe, type:

Witadmin /?.

First, export the existing Categories settings document which specifies the Work Item Types that can be used throughout TFS, Visual Studio, and MTM. To export the XML file, type:

Witadmin exportcategories /collection:http://icstfs.ldschurch.org/tfs/UpgradeFromICSTFS2008 /p:<Your Project Name> /f:”C:\Users\<Your User Name>\Documents\TFScategories.xml”

Once that is downloaded to your machine, you can modify it and then import it back to the TFS Server. Open the TFSCategories.xml file and find the category to be changed. In the case of adding more acceptable WITs to become suites in MTM, look for the following section:

<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
  <DEFAULTWORKITEMTYPE name="User Story" />
</CATEGORY>

Make the desired modifications by adding lines that specify the other WITs to be added. The changes should look something like the following:

<CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
  <DEFAULTWORKITEMTYPE name="User Story" />
  <WORKITEMTYPE name="Requirement" />
  <WORKITEMTYPE name="Task" />
</CATEGORY>

Once the XML file contains the desired changes, it needs to be saved and imported to TFS. Type the following to import it:

Witadmin importcategories /collection:http://icstfs.ldschurch.org/tfs/UpgradeFromICSTFS2008 /p:<Your Project Name> /f:”C:\Users\<Your User Name>\Documents\TFScategories.xml”

It will be necessary to close and restart Microsoft Test Manager if it was open while making the changes. After restarting MTM, it should be possible to add Work Items of the newly added types to the Test Plan as suites (or requirements).

Test Manager Tool - Introduction

The Microsoft Test Manager 2010 is a new manual testing tool that integrates fully with Team Foundation Server 2010. This tool is designed for the Test professional, and integrates the management of test plans along with their test cases into the full development lifecycle of a Team Foundation team project. It delivers another degree of traceability in your projects through the tracking of test cases and the results that flow from the running of test cases. You can even generate a bug directly against a test result. Visibility is increased because results are reflected in reports that provide test status along with work progress for each requirement. If you are using TFS 2010 and are serious about effectively tracking defects throughout your project, you should take a hard look at Test Manager 2010 to determine if it meets your needs.

This walkthrough assumes that you have some familiarity with work items in TFS 2010, such as User Stories/Requirements, Bugs, and Tasks. I will be posting a later blog on use of hierarchical work items in terms of effective work item relationships. I will also consider following up with a getting started blog on Automated testing, as I know there is a lot of interest in this area.

From the perspective of Test Manager, we have a three-layer hierarchy as follows:

• Test Plan – you begin with Test Manager by creating a test plan
• Test Suite – within each test plan, you may have multiple test suites
• Test Case – each test suite is composed of multiple test cases

The first time you launch Test Manager, you will have to point it to the TFS team project you would like to work with, as this project will be needed for Test Manager queries, and is where work items generated by Test Manager will be stored. Of course, work items generated by Test Manager will be available to the team members using Visual Studio 2010 and Team System Web Access. I selected my desired project and selected “Connect now,” as seen below.

Once you have selected your team project, you will see the list of current test plans (note that I have three test plans, and will select the test plan named “Walter’s Test Plan” that I just created):

When you select a plan, you are taken to the Testing Center as seen below, defaulting on the uppermost Plan tab and the lower Contents pane. Your test plan is the topmost node in left-hand pane, which will have test suites as children. On the right-hand side are the test cases that comprise the selected test suite. In order to add test suites, you have the following options:

1. Create a new, blank suite
2. Create a new, query-based suite which will allow you to select one or more existing test cases in TFS
3. Create a new suite based on one or more existing requirements in TFS
4. Copy test suites from another plan (the curved arrow button)

The first order of business is to set specific properties on your test plan, by selecting theProperties pane as seen below. On this tab you can select the Area Path or Iteration for your team project, assign what build you will for the test plan, specify different test configurations, and see the current status of test runs. Note that I have setup the following configurations: Windows 7 and IE 8, Windows XP SP3 and IE7, and Windows XP SP3 and IE8. These are the most common configurations, so we will want our tests to pass in all three environments. From the Configurations dropdown, you can also manage your configurations.

If your “Test settings” dropdown is currently <default>, then select “Local Test Run.” Afterwards, click the “Open” link next to the dropdown, which will yield the Test Settings window seen below. Click on the “Data and Diagnostics” link.

You will now see options for capturing information during the test that will be helpful when creating a bug. If you want a video recording of your desktop session while you run a test (e.g., you may want to record a bug repro), you can choose the Video Recorder option. Use this judiciously as the .wmv files can get big. Obviously, they won’t work well over a slow link.

Go ahead and make your desired changes or cancel out of the Test settings window, and let’s take a look at configurations in the Contents pane. We have the Default Configurations dropdown, which in this case at the test suite level is inheriting default configurations to be tested from the parent (which is the test plan). Still, we must select the configurations we actually will perform in the test run for a given test case. So at the level of the test case, we can select the configurations that are applicable to this test case.

I have selected the Configurations button, which takes me to the following window, where I have selected two configurations to test for this test case, as seen below. You will see this reflected later during the test run.

I went ahead and selected the “Apply changes” button, which takes us back to the Contentspane, where we will add a new test suite based on existing requirements. Again, this is just one way of creating new test suites. We will now click the “Add requirements” button, as seen below.

You will now see the query window that will load all requirements in this team project, as seen below. You would click the “Run” button to execute the query. (Note that in my query, I have modified the query to only return User Stories that have been marked as Features. This is because I’m using a modified MSF Agile 5.0 process template that implements a three-tier hierarchy from requirement to task. Specifically, my hierarchy is Feature – Capability – Task. You can find out all the details and download the process template at my blog post here.

Next, you can select one or more requirements to add to the plan, and then select the “Add requirements to plan” button.

Now we have a new test suite based on a specific requirement, as seen below, and we can begin creating new test cases or incorporating existing test cases into this suite using the right-hand pane. Had I selected multiple requirements, each would have a corresponding test suite in the list below.

I have already created a test case, so instead of creating a new one, I will select the Add button in the right hand pane, which will take me to the query window as seen below. This window will allow you to select one or more existing test cases. I went ahead and ran the query, selected one, and selected the “Add test cases” button.

So now we have our test plan, test suite, and test case.

We can now open the test case by double-clicking or performing a right-click and selecting the “Open test case” menu option, as seen below.

Below is the test case, which in this case has a Shared Step with parameter values (Shared Steps is just one other work item type in TFS 2010). You can share steps between manual test cases by creating shared steps. For example, the test steps to log on to your application under test might have to be run in several test cases. By sharing the steps, you can just maintain changes in the shared steps only. You can get more information on shared steps from the MSDN library online here. The parameter values below driven by the shared step represent the number of iterations you will run, which in this case is three iterations.

Let’s see how we would create a shared step. From the New dropdown in the upper right-hand corner, we would selected the Shared Steps menu option, as seen below.

So here is the shared step I have created below, which is a simple two-part step of entering user authentication credentials and selecting the “Go” button. The @ sign allows us to create iteration-specific variables to be used during the manual test pass. In this case we have two variables, Username and Password. I could put the actual values in the table below within the shared step, or put them in the test case that is using this shared step. In this case, I will put the iteration variables in the test case (as seen above).

Now we will close the shared step, and then close the test case. We will next select the Testtab at the top of the window, which will take us to the Run Tests pane.  We see below that we have two test runs for the same test case because we have two different configurations that were selected. In this case, for the test case must be run in Windows 7 with IE8 and Windows XP SP3 and IE8.

We will now right-click on the test case for the Windows 7 and IE8 configuration, and select the “Run” option in the menu.

The Test Manager is closed and the Test Runner is launched.  Below is the Test Runner at the beginning of our test.  The existing action recording associated with this test case will be overwritten (since I have run this test before), beginning with Iteration 1 of 3.

We now follow the steps in Iteration 1, as shown below, checking off Pass/Fail for each test step. When we get to the Shared Step, we will record this step for subsequent iterations by selecting “Start and Record.” You must select this if you want to data bind fields in the Shared Step for later Fast Forward.

After we select “Start and Record” for the shared step, when I click in the Username field of the browser, it begins recording in this window and places a “Currently Recording” icon in the upper right-hand corner of the browser window.  Once I type my values in the Username and Password fields, in that order, the Test Runner has now data bound itself to those fields for subsequent “Fast Forward” iterations in this test run.  Note the database icons that appear after I have tabbed out of the mapped fields, indicating the data binding has been successful.

When recording the Test Runner will provide a handy little graphic to the far right on the title bar of the application whose actions it is recording. The graphic looks like this:

Okay, so I have now selected that everything has passed in this iteration, and then selected the “End Shared Step” as well as “End iteration and move to next” links as seen below.

After you click the “End iteration and move to next” button, you will see the dialog below. Go ahead and overwrite the existing recording. What this means is that this particular shared step has been recorded and is now data bound to the browser page on whose actions we just you recorded. We can now take advantage of Fast Forward, which we will do next in Iteration 2.

Now the Test Runner takes me to Iteration 2, and I can now use the “Play” dropdown to select the “Play all” button, which implements the Fast Forward feature. My actions recorded in Iteration 1 are played back, and all I have to do is to select Pass/Fail for each step in the test iteration. Since all went well, I then manually selected that each step has passed:

We end this iteration and then perform the same “Play all” Fast Forward process for Iteration 3, and select the “End iteration” button to finish the test run:

After selecting “End iteration,” the Test Runner automatically selects the “Pass” dropdown in the upper right-hand corner since all steps have passed in all iterations.

Note that you can select the Pass/Fail drop down and select otherwise, as seen below.

You would then select the “Save and Close” button above, which will take you back to Test Manager, where you will now see your test case is marked as “Passed.” Also note that our status bar in the upper right-hand corner of the pane shows that we are 50% complete in our testing (blue indicates Active, and green indicates Passed).

You can now see the results of the test run by right-clicking the Test Case and selecting the “View results” menu option.

This yields the following test result window, where you can see the results of each iteration, test step details, attachments, and test case result history.

We can collapse the Test Step Details section, and expand the Attachments section which shows diagnostic files generated by the Test Runner, as seen below:

We didn’t have a bug, but for your edification, you can now create a bug directly from this test result by selecting the “Create bug” button, yielding the following window below. This is real coolness.

If you select the “All Links” tab in the Bug, you will see the attachments from the test run above are included in the bug, providing the developer with a wealth of diagnostic information to help with investigation of the bug (per above, this can also include a video recording of the test run).

Once the bug is filled out and saved, a developer can then query on bugs assigned to them and find them in Visual Studio 2010.

From a reporting perspective, you can see below what you gain from the integration of Test Manager 2010. This is the Stories Overview report, which shows, for each requirement, its work progress and test status that includes bugs reported against the requirement. You have an excellent visual in this one report to tell you overall how your project is tracking.

That’s it for our adventure through Microsoft Test Manager 2010. Hope this helps to get you going. This is a great tool with excellent TFS 2010 integration that will make managing test plans much less painful in a TFS 2010 environment and will provide full visibility into test progress as well through reporting.

More about the Sun

It's time to stop thinking of solar energy as a boutique source of power, says Joshua Pearce.

Sure, solar only generates about 1 percent of the electricity in the US. But that will change in a few years, says Pearce, an associate professor of electrical engineering and materials science at Michigan Technological University. The ultimate in renewable energy is about to go mainstream.

It's a matter of economics. A definitive new analysis by Pearce and his colleagues at Queens University in Kingston, Ontario, shows that solar photovoltaic systems are very close to achieving the tipping point in many regions: they can make electricity that's as cheap -- sometimes cheaper -- than what consumers pay their utilities.

Here's why. First, the price of solar panels has plummeted. "Since 2009, the cost has dropped 70 percent," says Pearce. But more than that, the assumptions used in previous studies have not given solar an even break.

"Historically, when comparing the economics of solar and conventional energy, people have been very conservative," says Pearce.

To figure out the true cost of photovoltaic energy, analysts need to consider several variables, including the cost to install and maintain the system, finance charges, how long it lasts, and how much electricity it generates. Pearce and his colleagues performed an exhaustive review of the previous studies and concluded that the values given those variables were out of whack.

"It is still a common misconception that solar PV technology has a short life and is therefore extremely expensive," he said. However, PV panels are solid-state electronic devices with no moving parts and should last a long time. "Based on the latest long-term studies, we should be doing our economic analysis on a 30-year lifetime at minimum," Pearce said.

In addition, most analyses assume that the productivity of solar panels will drop at an annual rate of 1 percent or more, a huge overestimation, according to Pearce. "If you buy a top-of-the-line solar panel, it's much less, between 0.1 and 0.2 percent."

Finally, "The price of the solar equipment has been dropping, so you'd think that the older papers would have higher cost estimates," Pearce said. "That's not necessarily the case." Equipment costs are determined based on dollars per watt of electricity produced. Very recent studies set the amount between $2 and $10. The true cost in 2011, says Pearce, is under $1 per watt for solar panels on the global market, though system and installation costs vary widely. In some parts of the world, solar is already economically superior, and the study concludes that solar will become an increasingly economical source of electricity over expanding geographical regions.

In regions with a burgeoning solar industry, thanks to government programs that pay a premium for renewable energy, there are lots of solar panel installers, which heats up the market. "Elsewhere, installation costs have been high because contractors will do just one job a month," says Pearce. "Increasing demand and competition would drop installation costs considerably."

Furthermore, economic studies like Pearce's don't generally taken into account solar energy's intangible benefits, reduced pollution and carbon emissions. And while silicon-based solar panels do rely on a nonrenewable resource -- sand -- they are no threat to the world's beaches. It only takes about a sandwich baggie of sand to make a roof's worth of thin-film photovoltaic cells, Pearce said.

Based on the study, and on the fact that the cost of conventional power continues to creep upward, Pearce believes that solar energy will soon be a major player in the energy game. "It's just a matter of time before market economics catches up with it," he says
.