A new mouse has hit my desk - the so-called Cyborg R.A.T. 7. It's not yet available in Australia, it's been shipped straight from Mad Catz themselves! But, they didn't do it because they love me, it's a review unit so I could analyse it. And analyse it I did!

Check out that link to the review, and leave your feedback. :)

Benchmark Reviews has an article on building a bang-for-buck enthusiast PC, for Q3 2010. If you haven't already heard, I recently joined their team of contributers, and this is my first article there. Here's a short snippet.

Performance is often attributed to expensive objects of desire. In the automobile space, it's generally accepted that a higher performing vehicle will incur a significant markup over the average fuel-efficient family offerings. Computing is much the same. Retail OEM machines are pre-built at predetermined price points, often targeting the humble office/Internet-centric user. Performance isn't a primary concern for these systems, nor are upgradability or customisation. On the other hand, you have the expensive 'gamer' orientated machines which cost several thousands of dollars! This is where Benchmark Reviews steps in. We've sat down and created three enthusiast machines without the dreaded price gauge of many pre-built setups - the 'Enthusiast PC Build' for Q3 2010!

Keep in mind that prices are in USD. You can read the full article here.

Apparently someone at Google didn't realise that people can use  <script> tags to insert scripts in YT comments. Naturally, 4chan and ebaumsworld have discovered this vulnerability, and have spammed all popular videos with lord knows what scripts.

Some videos are redirecting to malicious sites, others have explicit content, or offensive marquee text.

Just thought I'd warn you all. Afterall, scripts are very dangerous. If you have visited YT lately, please ensure your PC hasn't been infected.

If you have an infected video, please disable comments.

Update: Youtube have removed the offending comments.

Netcasts (also known as webcasts) are the new age talkback radio. They're an audio file - sometimes pre-recorded, other times live - which is broadcasted via the Internet. The popular 'podcasts' are a derivative of netcasts, but are typically restricted to the iTunes distribution channel. The term 'podcast' is often abused and used in place of netcasts, much like how the term 'iPod' is used in place of 'MP3 player', despite the brand. From a technical perspective, a netcast is just an ordinary audio file, typically MP3.

I've collated some of my favourite tech netcasts for you all to enjoy!

TWiT Network
TWiT is arguably the most popular netcast network in the world. Regularly topping the podcast ratings in iTunes, TWiT broadcasts shows which cover all corners of technology - and more! The founder Leo Laporte participates in most shows, and has been hailed the President of the Internet by TechRepublic in a mock election. His great personality and long history of radio produces entertaining and intellectual shows with his regular hosts and guests alike.
If you want to keep up with tech, the TWiT network is hard to pass up.

AtomicMPC
Atomic's new podcast is all about enthusiast tech, covering articles in their magazine, trade shows, and anything else that stumbles into their labs. Being new, it's still getting on its feet, but it's a good listen nonetheless.

Engadget Podcast
Humour, awkwardness, tech - that's the Engadget podcast! Editors from the popular tech blog Engadget meet up once a week to talk about the latest news and reviews in the tech world. Definitely one you want to add to your netcast feed!

PC Perspective
PC Perspective is the netcast associated with the popular review site of the same name. The host Ryan Shrout and his panel of guests talk about the latest in enthusiast computing hardware. This netcast is a great way for enthusiasts to keep up with the ever expanding world of hardware.

So, what do you listen to? Let us know in the comment section below!

There's an abundance of utterly hideous equipment on the market, ranging from mobile phones to desktop computers to anything designed by a collection of stale engineers. Sometimes it's a subtle flaw, such as an upside-down logo on your laptop lid. Other times you'll come across something that's so insanely blemished, that you struggle to comprehend the fact that a living human being produced and released this device to the market - at least, not with a straight face.

With the aim of outing the design flaws which plague the consumer tech industry, I've written a few specific examples which clearly explain why some 'features' are best left to concept art.

Gloss
Perhaps the most prevalent, glossy paint jobs are used anywhere there's a need to cover cheap plastic and subpar design choices. It's as if designers look at the product, know it sucks, and think that gloss is the magical solution to the whole mess. Well, it isn't.
Glossy hardware is a magnet for body oils, including figerprints or residue from your lunch. It looks cheap when it's clean, and revolting when it's been used for five minutes. If a manufacturer is keen to go at a design with a gloss covered brush, at least make it resistant to prints. Otherwise, stick to matte.

Chrome, real and fake
Chrome is another ugly trend. Both real and fake scratch into an awful palette of circular scarring, the latter looking like a knock-off from the local two dollar shop. As with gloss, it attracts fingerprints, and breeds compulsive shirt wiping. And don't get me started on fake carbon fibre - c'mon, these things ain't cars!

Screen border
This one is a problem with portable devices, and to an extent, monitors. So many touch screen phones have an insane amount of plastic framing around the screen. With the advent of capacitive screens, your entire attention when using a modern phone is directed to the screen itself. Both control and display are all in one, so perhaps manufacturers should build the phone around the screen, not just shove it where it'll fit. An excellent example of this is the HTC Evo 4G.

An example of good screen usage

Regarding monitors, the frame gets in the way of multi-monitor setups. For example, using Eyefinity for gaming would be much more attractive if the gap between screens was minimal.

Stickers
No one cares about what fancy features are part of their device - we already know, we bought it! At least make them remove easily, leaving a sticky mess isn't going to win you any favours.

Branding
If you're a small company, and want to make a name for yourself, don't plaster it all over your product! Sure, put it on there, but be subtle about it. If you're not a household name, then you'll probably find excessively branding your products will do more damage than good. There's only so many times people will put up with "What the heck is VuvuzelaTec?" every time they take their device out in public.

Cheap build
No one wants to pick up a product and feel it buckle under their moderate grip. It might be cheaper to skimp on structural integrity, but customers hate it. Are you building a product for people, or margins? It's particularly bad when you can see the warping of the frame, thanks to reflections in the glossy exterior!

There's a lot of odd design choices when creating products. What irritates you? Put your response in the comment section below! :)

Not to be outdone by insignificant humans, IBM's Watson supercomputer has made an appearance in a behind the scenes sneak peak video, showcasing its ability to answer complex natural language questions in real-time. Watson is one of IBM's latest projects, designed to push the boundaries of computing hardware/algorithms, and ultimately, produce convincing artificial intelligence. But, IBM aren't aiming to pass the ever conquering Turing test. Instead, they're going to compete during an episode of the American quiz show Jeopardy! using Watson as a contestant. Excited? Watch the video below and bask in its awesomeness!

Microsoft have announced a new name for their Xbox 360 motion-tracking peripheral today. The Microsoft Kinect - a play on 'kinetic' and 'connect' - allows users of the XBOX360 console to interact with their games and media without a physical controller.

Kinect is expected to sell for $150USD, and should be available for purchase in the near future.

Video chat for up to four persons simultaneously is also rumoured, along with a slimmed down Xbox 360 model.

Check out the possible uses for Kinect here!

Sources: Major Nelson via Engadget

Would you look at that, I'm now on Twitter! Now you can get updates in 140 character snippets! Get in on the action at:

www.twitter.com/vitocassisi

- Vito

I'm sure you've all heard about Australian Senator Stephen Conroy's craziness during a recent press conference. The pro-filter communications minister had a few things to say about the usage of portals, and their habit of being targets of malicious spam.

But, I'm not here to regurgitate prior news. Nope. I'm here to reveal that Conroy was hinting at the upcoming game Portal 2 (sneaky!). And I have proof!

Ok, so it's not really the new Portal game, but I must say, Conroy had me convinced! For those starring at me blankly, here's the footage that explains it all:

Let's just hope he's better at protecting portals than he is at protecting children. :)

Before delving into the software and physical development of BOB++, it's important to get a good idea of the tactics that the robot will perform. Making a sumo bot involves many behaviours which are critical when encountering a dynamic opponent. This worklog encompasses the behaviours which will eventually be implemented using LeJOS and Java Integrated Development Environment (IDE) Eclipse.

Note: You can find the previous worklog here.

The Static Environment
As we know, all battles are held within a small ring. This nature of the ring is known well in advance, which provides a point of reference when developing the robots behaviours. The rules of the battle are also used to determine what actions the robot can, can't and should take. These factors are always considered when creating a behaviour.

The Dynamic Environment
The opponent robot will behave unpredictably, unless you design your robot to find patterns in behaviour. Since prediction is very difficult to implement, it is wise to design a robot to act on events as they occur. These events are many and varied, and it can become tempting to scheme up elaborate solutions to specific situations. The most effective way to design behaviours is to think about the core functions that the robot will need to compete, and how they can be implemented. Once you have a functional robot, elaborate algorithms may be warranted. That being said, the best approach is to keep things simple, and to prioritise the behaviours you wish to develop. For instance, 'seeking the opponent' is of a much higher priority than 'rip their wheels off'.

So, what will BOB++ do?
After some thought, I've decided on a few core behaviours. I've created the following list, however I may alter them later if required.

Seek
The seek behaviour is insanely trivial, but will provide the basis for navigation in BOB++. When an object isn't in sight (according to the ultrasonic sensor), the two drive servos will rotate in opposite directions. This will cause the robot to rotate on the spot. If an object is detected, the EMF breaks are applied to stop the robot as accurately as possible. It will then move toward the object. If the robot loses sight of the object, then it will rotate again - rinse and repeat.

Lift main weapon
If you look back to the last prototype, you would have noticed the main weapon - a lifting device. This weapon is used to (hopefully) lift the opponent partially or completely off the ground. Doing this will make it easier to remove from the ring.
This behaviour dictates when to lift the main weapon. If an object is detected within 10cm of the robot, the main weapon will raise. The 'seek' behaviour will still be running, so the robot will be moving forward at the same time. If the robot loses sight of the object, or the edge of the ring is detected (via the light sensors), the lift will lower again.

Edge tracking
Tracking the edge of the ring is essential when competing. Even when running solo, it is difficult to keep an autonomous robot within the small bounds of the ring. Detecting the edge allows BOB++ to act immediately when leaving the ring.
The edge tracking behaviour of BOB++ will immediately halt BOB++ on detection of a black line. If the weapon is up, it will be lowered immediately. The robot will then reverse a distance of 15 cm. The 'Seek' and 'Lift weapon' behaviours may take over during the reversal.

Disorientation correction
Due to the nature of BOB++'s weapon, it is possible that BOB++ may start to flip if attempting to carry an excessively heavy load. For the reason, a touch sensor will be fitted to the rear of the robot. When the robot is firmly on the ground, the touch sensor will be pushed by the weight of the robot on the rear wheel. If the robot starts to lift, the touch sensor will release, and the robot will be alerted.
When the touch sensor reports false, i.e. it's not being pushed down, the main weapon will lower in an attempt to reorientate the robot.

These are the only behaviours I'll be implementing at first. The current prototype hardware design facilitates the above, apart from 'disorientation correction'. Fortunately, this behaviour is not necessary to compete, thus can be assigned a lower priority.
In the next worklog, I'll be implementing the seek and attack behaviours using Java and Eclipse.

I've been busy, and a robot has emerged from the Lego filled trays that occupy my desk. Usually I'd document the building process as I go, but I decided to build the thing bit by bit between doing uni work, thus documentation was left to last. So, I'll be analysing my first finished prototype as a whole, whilst focusing on individual design choices and implementations. Here we go!

Note: You can read the previous log here.

BOB++ v3.0 Prototype 1

The first prototype is quite different from the original BOB++ design. The servos have been placed perpendicular to the Intelligent Brick. The reason for this was to combat a couple of issues, the first being structural integrity. The original design had the servomotors adjacent and directly attached to the Intelligent Brick. Although this allowed for a low centre of mass (the Intelligent Brick is heavy with batteries installed), the mounting points were insufficient to secure the servos without them being moderately loose.

The old servo connection.

The current prototype fixes this by removing the direct connection, thus allowing a frame to be built around the brick. This frame can then facilitate the servos in addition to other sensors. A strong frame is superior to connecting everything directly to the brick since the available mounting points are often awkward to use.

Having the servos mounted as they are in the prototype was a decision to allow:

a) A frame to be built without the servos being in the way.
b) The servos to be mounted to the front of the robot to prevent an overly wide design.
c) A low centre of mass.

The position of the Intelligent Brick is improved over the original design, particularly in regards to battery access. The bottom of the brick is now completely accessible, meaning the battery door can be removed and replaced without issue. On the other hand, the LCD display and brick controls are difficult to access due to the overlying frame. This isn't much of a concern since there's a sufficient gap to navigate the firmware menus, and the screen can be read if need be. At least I don't have to rip the robot apart to charge the batteries!

You may have noticed that there's only two rubber tyres on this build. This is because I plan to bring across the spin behaviour its predecessor utilised. This involves rotating the two drive wheels in opposing directions, causing the robot to rotate on the spot. Since this spinning motion causes the back wheels to slide perpendicular to their rotation (i.e. to their side), I decided that it'd be better off to have a single low friction rear wheel. At this point in time its a solid plastic wheel, however it'll likely be replaced with a trolley wheel in a later prototype.

The ultrasonic sensor is at a higher level than before. The position of the sensor was chosen to allow for the main weapon to move freely at the front end of the robot.

This may change since there's a chance it'll overlook close opponents with a small physical profile, as seen below.

At first you may think that the solution is to aim the ultrasonic sensor on a larger angle...

This doesn't work well, though. It severely limits the scanning range of the sensor since it's always looking at its "feet". The solution is to move the ultrasonic sensor to a lower position if possible.

Last but not least, there's the lifting mechanism. This has been drastically changed to allow for a smaller profile, stronger lifting power, and reduced chance of self inflicted damage (such as failing under an opponents weight).

Perhaps the most obvious change is the length of the lifting mechanism. The previous model was quite lengthy to ensure an opponent was well positioned to be flipped or carried away. This does not come without disadvantages. A large distance between the load and fulcrum (turning point, i.e. the servo) will give the opponent a greater mechanical advantage. What does this mean? Think about when you're opening a door. Is it easer to push it from the outer edge, or near the hinges? Try it, and you'll soon realise that the further away you are from the fulcrum (or hinge), the easier it is to manipulate. This is also why you can lift something easier if you shove a large stick/plank/etc. under it and push down. The effects of mechanical advantage are found everywhere, but are usually associated with simple machines.

One equation of mechanical advantage is the following:

In this situation, the load is my robot, and the effort is the weight force of the opponent acting on the lift. Therefore, the longer the lifting device, the larger the application distance of the effort force. This increases the numerator value of the above equation, which as we know, means the MA value will also increase. Unfortunately, the 'advantage' is not ours, and if it's large enough, it will either flip the robot or damage the lifting mechanism. This is precisely why I've shortened it.

In addition, the gearing set up has changed. Previously we had a 8-tooth gear attached to the servo (acting as the drive gear), and a larger 24-tooth gear attached to that. This resulted in a gear ratio of 1:3. In layman's terms, this means for every rotation of the smaller gear, the larger one will move 1/3 of a rotation, or 120 degrees. Why do we want this? The sacrifice in speed of rotation gives us a larger torque value (which is inversely proportional to the speed). When we're trying to lift a heavy object, speed is not nearly as important as power, and torque gives us that power.

The original gear set up. The 8-tooth gear is not visible.

Since the servos are quite fast, I altered the gear ratio to the following in the current prototype build:

The drive gear is still a 8-tooth gear, and the gear directly proceeding it is also the same 24-tooth gear. This time I've added a 40-tooth gear to bring the gear ratio to 1:5. This is a 40% torque increase from the previous design.

What's next?
And that's it for this log! More to come soon, including design alterations, and a bit of logic programming!

Considering the public perception of robotics, if you were to ask someone to help you construct a robot, the chances of them accepting would probably be influenced by their technical enthusiasm. A layperson will likely assume it's beyond their abilities, which is not necessarily the case. This is why I've started this worklog, I want to give people a look at the development of a simple robot. If anything, it'll get more people interested in robotics. :)

For the sake of intuitiveness, I'm going to be using Lego in this project. It's great for modelling physical structures, and the Mindstorms kits make the process of assembly easy. More specifically, the kits of interest are the NXT and NXT 2.0 models. I'll be working off the original NXT kit, however version 2.0 is very similar, and for the most part interchangeable with the first. Before you shout "But Lego is for 8 year olds!" I'll put things into perspective. I will only be using the NXT hardware. That is, the 'brain' of the kit, also known as the Intelligent Brick, will be re-flashed with LeJOS firmware. This allows me to program the robot in Java. For the uninitiated, Java is an object orientated programming language which is commonly used for cross-platform applications, mobile phone apps, and Internet applets. Wherever there's a Java Virtual Machine (JVM), you can run a program written in Java. This is what LeJOS provides - a compact JVM.

Note: This worklog isn't a tutorial. It's a written update of the work I'll be doing on this robot. I'll aspire to include as much information as I can to assist anyone who wishes to use it as a guide. I will be writing a separate step-by-step tutorial, and will inform readers when it's completed.

What's the robot for?
The robot is a remake of a project my UNSW ENGG1000 team and I built over a year ago. We called it BOB++ (don't ask), and its sole task was to sumo wrestle. The goal of the project was to compete in the annual ENGG1000 SumoBot competition - and win. The higher you made it up the competition ladder, the more marks you got. Without getting into too much detail, our robot was significantly hard to beat. We won 5/5 qualification rounds, before getting into the final. This match was almost called a draw due to the length of time the robots were fighting; we had almost broken the 3 minute time cap. Unfortunately, a brief slip of our drive wheel allowed the opponent to remove us from the ring. Nevertheless, in the grand final, where the three best robots were placed into the one ring, BOB++ didn't hesitate to barge both opponents out ASAP.

It was sweet revenge.

What are the rules of the competition?
Much like a traditional Sumo fight, the aim of the game is to remove the opponent from the ring. This ring is 500mm in diameter with a 15mm non-reflective black borderline. The inside of the ring is white.

During play, the following rules must be followed:
- Robots cannot fire projectiles
- Robots cannot intentionally damage their opponents
- The first robot to have more than 50% of itself outside the ring loses
- Robots must not exceed 1KG
- If a detached part of your robot is removed from the ring, you lose
- A robot must wait 3 second after being activated before moving; the match officially starts after these 3 seconds
- A robot must move within 10 seconds of the match starting, otherwise it's disqualified
- A match is a draw if 3 minutes pass without either robot winning
- The robot must be autonomous; you cannot use the inbuilt Bluetooth functionality

The initial starting positions are as follows:

How did BOB++ work?
BOB++ was built using a Lego NXT educational kit. A typical kit includes a multitude of Technic pieces, an Intelligent Brick, three servos, and a range of sensors including:

Ultrasonic sensor
Uses ultrasound to determine the distance between it and another object.

Sound sensor
Determines the decibel (dB) loudness rating of ambient sound.

Touch sensor
Basically a simple switch. It's either on or off, the former being when the button is held down.

Light sensor
Determines the intensity of ambient or active reflected light. The latter is achieved via a red LED on the sensor.

The ENGG1000 course permitted the addition of a second light sensor.

Instead of using LeJOS, we were told to use NXC, which is based off the C programming language.

The design of BOB++ was quite simple. We focused on creating a robot which was simple to build, simple to program, and highly effective. The main weapon was a lifting mechanism attached to the front of the robot. When an enemy was in range (as determined by the ultrasonic sensor), the lifting mechanism controlled by a single servo would raise. The aim was to get close enough so that we could lift the opponents drive wheels off the ground. If nothing was in range, or the edge of the ring was detected, the lift lowered itself.

During some trials, we noticed that our robot was capable of lifting itself off the ground if the opponent was heavy, or if the lift got stuck. To determine this, the touch sensor was placed near the rear of the robot so that it was always touching the ground (i.e. it was always on). If the robot starting lifting from the floor, the touch sensor would turn off, and the lift would know to release its load.

Since the ultrasonic sensor was fixed, we set the default robot movement to spin until another robot was detected, effectively giving the robot a 360 degree view. The robot would move toward the enemy on detection.

The light sensors were attached on the front and rear of the robot to help determine when we were going outside the ring. If the light sensor detected a low light value (the black line representing the ring's border), appropriate actions were taken to remain inside, as defined by our program.

Note: We did not use the sound sensor.

BOB++

How can BOB++ be improved?
There are many ways the design can be improved. At this time, the main focus is to build the robot so that the following issues are addressed:

Easy access to the battery compartment
The mounting points on the Intelligent Brick are difficult to work with. Half of them are on the underside of the brick adjacent to the battery door. For this reason, it's important to make the Brick either removable, or to keep the underside unobstructed. This was a major issue with the original BOB++ robot.

Low center of mass
A lower center of mass means the robot is less suseptable of being pushed over by an opponent. Top heavy designs are easier to topple, so its a good idea to keep most of the weight near the bottom of the robot.

Structural integrity
BOB++ wasn't as strong as we would have liked. Several small changes before the competition meant there was less strength in the design. Fortunately this wasn't a problem in the competition, but it's always a good idea to have a solid design.

Enhanced behaviours
The AI in BOB++ was functional, but it had its quirks. For instance, the main weapon would forget its position on occasion, and try to raise the lift whilst its already at its highest point. Crunching of gears assured! There was also very little in the way of filtering data from the sensors. We opted to use raw data directly, which can be a problem if the sensors briefly report an erratic reading.

What's next?
That's all for now! In the next log, I'll get into building the robot and showing off my design decisions. I'll describe what I've done, and the reasoning behind it. Stay tuned!

However, I've got some goodies coming soon. I realise these 'sorry, but content is coming' posts are the modern day equivalent to the retro 'under construction' GIFs of yesteryear, so I won't blab on. :)

Sorry to the loyal regular readers who keep this blog worth writing for. I'll do my best to get an article done tonight.

Regards,
Vito Cassisi

Yes, you've read correctly, TPG is going unlimited! A representative of TPG who goes by the name 'Dan.S' has posted the following on Whirlpool:

TPG is pleased to announce an exciting up and coming change to our ADSL2+ product range. For this first time we will offer an Unlimited Broadband product for only $75 a month that has:

· No Shaping Speeds.
· No Time Limits or Time Restrictions.
· ADSL2+ technology.

What makes this even more exciting is that for an extra $1 our Home Phone Line Rental can be purchased as an optional add on at the time of purchase. A $10 Minimum call charge for TPG Home Phone applies. This product will be available at Limited Exchange Coverage areas only. More details to be provided at the time of product release.

Regards,
TPG Internet

This is a clear response to AAPT's unlimited offering, which costs $100 per month, but includes line rental and $50 of monthly music downloads.

Perhaps the greatest aspect out of all this is the ability to stream on-demand media without worrying about quotas. The day where we can finally dump optical discs for online entertainment services may well be upon us!

If you haven't done so already, here's your last chance to tell the Australian government that we need an R18+ rating for games! You can get the appropriate document here.

Don't fret though, it takes 10 minutes to fill out, and the comment section is optional (it's only 250 words anyway). When you're done, it's as simple as e-mailing the document to the provided e-mail address. Get to it!