I suck at writing blog.
But still, here's my point of view on the robots.

Small and agile with risks are what our competitors did during the K. Terengganu NRC.
They used the aim and shoot method.
This method basically is to make the robot move straight and grab ( other methods also apply) the object and put it to the destination.
They risk:

1. The position of the robot at start point must be EXACTLY where they have programmed.
2. Battery voltage must be EXACTLY the same as what they have programmed using.
   
3. Luck. No luck = GG
4. They must programmed it correctly in a sense that the programming must be accurate by the millimeter. And that's just too back-breaking for us?
5. Even the condition of the mat will AFFECT the performance AKA determine their fate.
   

THE SLIGHTEST MISCALCULATION, MISTAKES, EVEN BY A MM, WILL RESULT IN FAILURE.




But if, and if, they are:

1. Lucky
2. Able to program well
3. Makes no mistake.

They get lots of points as their robot is fast.


Next, is what we did.

Use Light Sensors to move with the black lines on the mat.

This method is:

1. More accurate.
2. May auto-recover.
3. Minimises human-error as the robot will move itself without requiring us to aim the robot.
4. It's now a fully-automated robot. No a car that picks up objects blindly.
   

Nothing is perfect. Same goes with this method.

It's :

1. SLOWER if compared with aim and shoot method. But if it's programmed well it may go faster ? ( unconfirmed, no chance for us to see others use this method )

Method of getting object.

This is gives us a headache till the very end of the competition.
We thought of all kinds of methods. Some fail. Some shines.
At last, we decided to go with the box method.
The robot's arm is a square that extends out of the robot.

The arm

We got frustrated thinking of other methods that we go ahead with a very straight forward box that just swoops in the object.

Well, this method brings a lot of problem.
Especially with the rubber object.
Rubber + mat = Friction and loads of it.

With the robot pulling the object, it's like telling it a mammoth task for the robot. It squeaks, jerks and even jumped over the object with the object still stationary.


There's also the grab method, grab-n-lift method, scoop method and so on.




It's late now. gtg. So, anything missing? Wrong? Bullshits? Please dump it in the comments.
And hopefully, I'll make up to it in my next post.




P.S. This is my first time writing and posting a blog post.

Point of View: Robot Massacre

Hello world ! This is my first post. Thanks to Eric for the invitation.
To make sure our robot will keep moving forward, I came up with these few questions and opinions that I believe is essential for our future robot construction.

First of all, the size of the robot. Our previous robot moves slow and steady although a bit bulky.
The mass of our previous robot is a pro and also a con. The weight is important to decide because it will eventually affect our turning, movements, power consumptions and of course the type/number of wheels. How can we give a balance "diet" for our future robot from being fat and slow? We can build it small and compact, mild and light or just with simple mechanisms.

I believe the robot should be small, simple and not-too-light.
Small, it is easier to build and does not interfere with the tracks or turnings.
Simple, just in case anything screws up, rebuilding it would be easier.
Not too light, a little bit of weight is recommended to prevent the robot from slipping, jerking and possibly gets off track.

Another thing to take note of is the sensors. It is always light sensors. Our previous robot is causing a lot of inaccuracy and failures on turning.
The obvious reason is the distance between the sensors and the wheels. The sensors shouldn't be too far from the wheels nor too close.
Our future robot should have a close enough distance from the wheels. So when the robot stops, the wheels are in the exact location as we want.

Arm mechanism. So called the pain in the ass.
Is there an arm design that could pick up almost every shape and sizes ?

Is grab-n-lift a good option ?
Do we really need an arm (guess so) ?

The following is the battery. Which battery should we use on competition day, rechargeable or new AA batteries? It would be best if we get some sponsorship from the school for batteries. Program using rechargeable then optimize it to a higher voltage, sounds good ? I believe the old design is a power hogging machine, therefore the new design must be small. It failed on the design and programming. Better design is a must. Until now, I'm still wondering how did we won third prize in the competition with this rotund golem.

Next, the wheels. Should we consider more than 2 wheels ? Do we need small wheels or big wheels? I think we are better off with big wheels (previous wheels).
The small wheels isn't giving much "grip" from what i see, and it may slip if we use a faster speed, it's just too light. The wheels are depending on the size of our robot. It's not like we put tiny wheels on a giant machine, that would be LOL !
Besides that, if possible, we're going for max power and max velocity. We never know what would happen next.

My views may be a little bit of obscure and ridiculous, I think you get the idea. Well, it's just my point of view.

Tell us what do you think about a winning robot.

Cheers.
-CH-

Quick engage/disengage mechanism for gear trains

Due to the challenging design of this year's Robot Energizing objects, many teams have come up with pretty interesting designs to carry the resources (i.e coal, bio-fuel, and esp. solar). One of the biggest challenge the teams face is to design some mechanism which can grab and lift the object by using only 1 motor as the other 2 have been used up for navigation.

So, some of the more successful teams have employed the grab & lift mechanism similar to the one shown below,

This is a brilliant solution for grabbing & lifting the Solar rescource off the ground, but there's a slight drawback to this design when the gear reduction ratio is too big - you need to turn the motor many rotations to reset it to the original position everytime the robot misses. So one the solution the teams come up with is to attach another knob/wheel along the driving axle for manual reset. However, this still takes up an awful amount of time, especially if your robot miss more than once :S

Recently i came across a very interesting mechanism that can engage/disengage a gear train with relative ease and i thought it would be an useful add-on to the grab & lift mechanism for quick engage/disengage in the event the robot misses the object.

I have uploaded the videos showing how the quick engage/disengage mechanism work along with the grab & lift mechanism without the quick engage/disengage mechanism for comparison.

Grab & lift with quick engage/disengage

Grab & lift without quick engage/disengage

This mechanism can even be applied to grabbers which uses wormscrews, which can save even more time on resetting the grabber.

Almost Famous - NRC 2009 Newspaper Article

I have been in Kuala Terengganu for less than 6 months, and I am already making a scene. Creating too much publicity is NOT a good thing :)

We had a little tiny article printed on the Sin Chiew 18 July 2009 about our recent win in the NRC 2009.

Since I cant read chinese, I can't give you a summary on what it says, but most probably only good things :)

Those who didn't see the article in their Sin Chiew is because it is printed in their equivalent of Metro section (The Star), where it only talks about local events in Kelantan, KT and Kuantan (East Coast).

NRC 2009 - 3rd Place Kuala Terengganu State

Here is a photo of the kids from SMK Chung Hwa Wei Sin with the 3rd Price win at the NRC 2009 Kuala Terengganu State level.

Congratulations to them on work well done of getting 3rd place. It is their first year with the NXT and coaching them from ground up is no easy task, not to mentioned with their busy schedules, they only had about a month to come up with their robot design and program for it.

Going against students who have got NXT experience, not to mentioned that they had already completed a similar NRC 2008 question is no easy task. Luckily with the long hours put in, they manage to obtain 3rd Place.

The kids are (from left to right)

• Cedric
  
• Koong (Chief Programmer)
  
• Chen Hui (Chief Builder)
• Eric Tan (Coach)

I expect nothing less from them next year, only First place would be acceptable!

I will be posting more on my NRC experience in the future post, as well as the design concept of our NRC 2009 robot, as well as mistakes that we had made.