Honda ASIMO Demonstration
Thursday, 12 April 2012 14:50
Niroshan Rajadurai
ASIMO (アシモ Ashimo) is a humanoid robot created by Honda. Introduced in 2000, ASIMO, which is an acronym for "Advanced Step in Innovative MObility", was created to be a helper to people. Apparently the resemblance to the name of Isaac Asimov is merely a coincidence. With aspirations of helping people who lack full mobility, ASIMO is used to encourage young people to study science and mathematics. At 130 cm (4 feet, 3 inches) tall and 54 kg (119 lbs), ASIMO was designed to operate in real-world environments, with the ability to walk or run on two feet at speeds up to 3.7 mph (6km/h). In the USA, ASIMO is part of the Innoventions attraction at Disneyland and has been featured in a 15-minute show called "Say 'Hello' to Honda's ASIMO" since June 2005. The robot has made public appearances around the world, including the Consumer Electronics Show (CES), the Miraikan Museum and Honda Collection Hall in Japan and the Ars Electronica festival in Austria.1
This is a demonstration of Honda's ASIMO humanoid. I captured this while at Disney Land (LA). It shows how ASIMO would function inside a typical household environment.
References
1. Wikipedia - ASIMO Reference
Last Updated on Thursday, 12 April 2012 15:41
|
Using C++ with Test Driven Development
Tuesday, 12 July 2011 15:45
ncr
Introduction
This whitepaper explains how Test Automation tools can be used with C++ to support Test Driven Development (TDD) in an Agile-programming environment. This paper assumes some basic familiarity with Test Automation products. Traditional Software Development Most projects currently use a test automation tool in a traditional development environment where individual C++ classes are unit tested as they are developed. This pure unit testing allows the developer to ensure that the low-level requirements attributed to a unit are implemented correctly, while at the same time verifying the completeness of the testing via code coverage analysis.
Figure 1 - Traditional Software Development - Waterfall Methodology
Since the code has already been written at this point, there are a number of issues in working this way:
- The identification of a potential defect in the code developed is delayed by several days, if not weeks, after it has been written
- There is a risk that developers will create unit tests based on the code developed, rather than deriving them directly from the requirements
- Code is over engineered, and more code is developed than is required to satisfy the project requirements
Last Updated on Wednesday, 13 July 2011 10:52
Read more...
Cache Theory 101
Thursday, 06 January 2011 10:38
Niroshan Rajadurai
Cache Lookup Strategies
Let's say we have a 32KB cache with 32-byte blocks (lines). This gives us 1024 blocks which can be held in the cache. When we want to look in the cache to see if a particular block is present, we can use one of 3 basic strategies:
- look in every one of the 1024 blocks to see if the block's tag matches our access address. This is known as a "fully-associative" cache, because any block from memory can reside in any block in the cache.
- use 10 bits of the access address as a selection index to one of the 1024 blocks, then compare that block's tag with our access address. This is known as a "direct-mapped" cache, where a particular block in memory can only go into one particular block in the cache. All the memory blocks that go to the same cache block are said to be in the same "congruence class".
- use a fewer number of bits of the access address as a selection index into a "set" of cache blocks, then search each element of that set for a tag match. This method is somewhere between a) and b), above, and is known as "set-associative". For example, if I divide the cache up into 128 sets of 8 blocks each, I have an 8-way set-associative cache which is indexed by 7 bits of the access address. A particular block in memory can then go into any of the 8 blocks in its associated set.
Last Updated on Thursday, 06 January 2011 11:25
Read more...
What code am I testing?
Tuesday, 11 January 2011 10:24
Niroshan Rajadurai
The importance of completely testing software applications, and achieving it cost effectively is currently one of the major growth areas in the software development tools industry. There are many tools that offer solutions for automating the unit and unit integration test process for our application code. These tools can parse our code, and from a few simple options automatically create test drivers to stimulate our code under test, and test stubs for our dependencies. While these tools vary in capability and automation, they all offer an improvement on current manual testing processes that are in place.
One of the areas that is relatively poorly understood, and perhaps glossed over in the selection of these tools, is the process they go through to parse the code under test and automatically build the test framework. Every unit test automation tool in the market today needs to parse the source code under test to determine types, and interfaces for functions to be tested, and implement stubs for its dependencies. As a result all of these parsers understand standard C or C++ code, however every compiler not only supports the standard C or C++ language, they have extensions.
Last Updated on Wednesday, 12 January 2011 10:24
Read more...
One Little Endian - Cross platform data handling issues
Wednesday, 05 January 2011 16:29
Niroshan Rajadurai
TCP/IP networks are rarely homogenous; they usually consist of a wide variety of machines, architectures, and operating systems - each storing binary data in various forms. The actual storage format is transparent as long as you access data locally (i.e., on the same machine). However, you must consider the data storage format differences when transmitting or receiving data across machines and networks.
Any data larger than a single byte can be store its bytes at least two ways: big endian order and little endian order.
Last Updated on Wednesday, 05 January 2011 16:38
Read more...
|
|
|
|
|
|
Page 1 of 2 |