I thought you might appreciate this video of my robot falling over.
At the end, you may notice that his legs get stuck together like an imperialwalker during the battle of Hoth! Ah, memories.
The instructions in the manual indicate very clearly that the nuts should be placed on the inside of the leg - presumably for aesthetic reasons. However, the short section of bolt which sticks out of the inside has a nasty habit of getting hooked on the opposite foot.
If you can tolerate your robot looking a bit road warrior themed, I suggest reversing the direction of the bolts to avoid having your robot flail about like a memermaid, and also the internal damage to the plastic casing:
I do oftencomplain about the robobuilder design, but I think I should make it clear that I am by no means unhappy with it. These are small complaints which (I hope) will be addressed by the robobuilder community and also allow others to avoid my mistakes.
The wCK servos are actually the best robotics servos I've used for their price. You can skip the durability issues I've beenhaving, simply by getting the wCK 1111 version, which has 3 metal gears and a higher torque! They have a suite of extra features, such as brake mode, 10bit positioning (360/1024 = 0.35 degree accuracy!), runtime adjustable PID settings, continuous rotation mode, and the ability to write simple programs to run on the servos themselves.
I have yet to use these features, but I can already think of a thousand uses for them.
I'm back from a short holiday down to the Melbourne Cricket Ground to watch the Boxing Day test. It was very relaxing, but now that I have returned I have lots of robot news to share!
Firstly, despite being unable to find wCK gears anywhere in the southern hemisphere, I have sort of fixed the broken knee servo. Thanks to an emergency surgical field graft, he can now walk fairly normally but has lost the use of his right arm. Apparently I'm not the only person who is havingproblems with the plastic gears. If you are concerned about damaging your own servos, I suggest you set them to the lowest torque setting. Note that 4 is the LOWEST torque setting, and 0 is the HIGHEST - the manual could probably be more forthcoming on this point.
Now that he's up and mobile again, I've resumed work on getting him to keep his balance while standing.
Whenever I start work on an ambitious project, I find that the only way to keep on track is set myself small targets along the way. I am always coming up with ideas that are easy enough to design, but take far longer to implement - and more than a few of them have fallen by the wayside because my eyes were bigger than my stomach.
So having small, short term achievements keeps me motivated to move on with the long term goal. A very simple method of controlling complex systems (particularly when computing power is limited) is called discrete state-space control. Rather than trying to model the system and predict how it will behave, the system is manually broken down into a discrete set of inputs and outputs. Then, using some very basic rules, the behaviour of the system can be described in very simple terms like: if A, then B.
In the case of the robot trying to maintain it's upright position, you can simplify things by firstly holding most of the joints rigid. Using the feedback information from the ankle servos (04 and 00), you can predict if the robot is tilting too far to the left or right. Then, depending on which state the robot is in, it can take the appropriate action to regain it's balance. Simple, no?
In the video, you can see the robot measuring the angular velocity of it's ankles, and detecting when it's balance is being compromised. It simply steps away from the force to maintain it's stability - just like a human would.
Right now, it only work for left and right - simply because the canned robobuilder animations for forwards and backwards consist of several steps, meaning I will have to write my own motions.
I should probably start putting together my own library of poses anyway, since I'm not too happy with the default ones. The walking and turning motions have a real problem on many surfaces - polished wooden floors are the best so far, but far from perfect.
Here you can see that the robot is having problems moving in the right direction with the stock SidewalkRight/Left actions, to the extend that he goes the wrong way! Because he was off centre to begin with, one foot is carrying most of his weight, so he pushes against the ground and towards my hand.
Code will be available soon, once I've cleaned it up a little and found a nice place to upload it. I think that robosavvy has personal file space for it's members, so I will see if I can make the files public.
In the absence of a robot capable of supporting it's own weight, I've started planning my next move.
The purpose of writing my own firmware for this robot is purely academic. I don't have a specific goal in mind for this project, even though I'm sure we would all enjoy a robot which could clean our house, bring you drinks, or make us coffee.
As I develop more and more features, I can share them as code snippets which will help other people with their projects. Of course, when I decide I want to revolutionize the coffee robot industry, I will be adequately prepared.
Now that I have figured out how to use the servos as sensors to get feedback about the robot's position, I plan to implement an inverse kinodynamics engine to enable balance without an accelerometer.
For those who aren't down with the lingo, kinodynamics is a contraction of kinematics and dynamics.
Kinematics is concerned with modelling the behaviour of a system given a physical and geometric configuration. In the case of the humanoid robot, this means calculating the relative location of the arms, legs, feet, etc, simply given the angular position of each of the 16 servos. This can be calculated (relatively) simply using basic (again, not something you'd find next to the funny pages) vector mathematics and trigonometry.
Now, dynamics. Kinematics merely describes the geometry and structure of an object. It's velocity, mass, angular momentum and behaviour when subjected to a force are all in the domain of dynamics. When your robot falls down the stairs in a hilarious but tragic accident, his dynamic behaviour determines how long you will watch in abject horror.
So, a kinodynamic model of a humanoid robot can be used to generate a fairly reliable prediction of the state of a robot at a future instant, given the current state and control space.
Put more simply, this model can be used to calculate "safe" actions, which will result in the robot performing a motion while keeping it's centre of mass over it's feet - in other words, balancing.
These are all quite lofty goals, and right now it looks complex, but I'll outline more details in future posts.
When I first got it into my head that I wanted to build a humanoid robot, I spent quite a lot of time researching various types of servos I could use. They needed to be high-torque, not too big and above all cheap - other features were just gravy.
This led me to consider a number of things, such as using unbranded RC hobby servos, buying unbelievably cheap micro servos and upgrading the motors, and even building my own.
These are not bad options, per se, but what I failed to consider were just how useful those extra features that high quality servos include can be.
Fortunately, I was saved from myself by the timely arrival of my birthday (which I have written about previously).
Though the wCK servos have many additional features, the one that I am finding particularly useful right now is the ability to query a specific servo for it's current position. Although it doesn't seem like much on it's own, it has enabled me to do cool little tricks like this:
The video simply shows me moving the robot's left arm, and having the program mirror the actions on the right arm.
Non-robologists don't seem to find this very impressive, but hopefully the implications of this are apparent if you are in the robot game. Effectively (although crudely), the robot now has a sense of touch.
Don't have a distance sensor? No problem - just set your robot into zombie posture and wait until one of his arms is bumped by a wall.
Worried that you'll damage a servo? Just check to see if it's stuck and turn it off to avoid stripping a gear.
Oh, and before you ask - yes, that is Donatello in the background holding the power and serial plugs.
Here's another video of him with his arms attached (the robot, not the turtle).
The servos are placed in passive mode, which is another special feature of the wCKs, which powers them up but turns off the PID control. Because the servos use an RS485 type bus, they can then be queried by the RBC and then take control of the bus to report their current position.
Although it is a minor achievement, this is another important step on the road to my grand plan. What plan, you ask? You'll just have to wait and find out.
The code is a bit sketchy at the moment, so give me a chance to clean it up before I upload it. Watch this space.
After what happened last time, I've become significantly more paranoid about damaging my robot.
Recently, while doing some more hacking of the wCK motion timing system, I decided to simply remove the element of risk altogether.
So far, separating the arms and legs from the body has been a good move (tm), and I encourage you to do the same if you start changing low level parts of the code.
You see, I am rapidly running out of those spanner shaped connectors.
I mentioned in a previous post how careless control over pointers can cause your robot to flip out like a hyperactive kid tripping over a beehive. The wCK servos have just over 11 kgFcm of torque, which is more than adequate to cause your robot to tear itself to pieces when a rogue pointer starts issuing random commands. I speak from experience.
Serial transmission of commands to the servos can be performed in two ways. The most common method is to use the "Transmission Buffer Empty" interrupt, to send a new character whenever there is nothing waiting to be sent. A transmission is initiated simply by unmasking the interrupt, and the interrupt is set to disable itself when there is nothing left to send. This is the preferred way of sending RS232 communications, as the interrupt will continually fire as long as as something remains to be sent.
The second method of transmitting the message is to use the "Transmission Complete" interrupt. If enabled, this interrupt fires whenever a character has finished being sent. This requires a single character to be manually loaded to "prime the pump", but transmission simply stops when no more characters are available. Since the next character is sent immediately, tighter control over transmission states can be achieved, such as when using an RS485 protocol.
The wCK servos use an RS485 protocol.
The reason that the robobuilder has a tendency to spaz out is due to two things. Firstly, the transmission buffer is circular. This means that messages can be added to the buffer at the same time as they are being sent. When the pointer gets to the end of the buffer, it simply returns to the beginning and keeps sending until it reaches the end marker.
Secondly, memory is never truly empty. A byte in memory simply contains the last thing that was stored in it. On reset, unallocated space usually contains junk data. Even if you set up your program to zero out your memory before you use it, it will still contain a zero. Therefore, even a small mistake which results in one of the transmission interrupts not being disabled correctly will cause a vast number of arbitrary commands being issued to the servos, causing the aforementioned spastic behavior.
Aaaaanyway, now that you know why it happens, you know how to avoid it. I still recommend detaching your arms and legs while you're testing though.
As promised, I have made some changes to the robobuilder source files so that movement commands execute properly.
The problem seemed to be that the wCK transmit interrupt was being disabled prematurely, before all of the instructions could be sent. General defensive programming practice on behalf of the designers meant that any function which placed commands into the transmit buffer intentionally waited patiently until the buffer was empty. This avoided accidentally fragmenting the instructions due to the limited size of the buffer, but meant that the program would just freeze up if (for whatever reason) the transmissions were not being sent.
With a little debugging, I identified the MakeFrame() function as the culprit, which was causing the program to get stuck waiting for the transmit queue to clear, but since the interrupt was disabled it stayed in an infinite loop. Simply placing a few lines inside the while loop making sure that the interrupts were enabled fixed the problem.
I also made a few other aesthetic changes - mostly making things more readable by replacing "magic numbers" with the names of registers. For the uninitiated, A |= (1<<X) means 'set' bit X in register A, while A &= ~(1<<X) will 'clear' the bit. The header file iom128.h in avr-libc contains the names of all the registers.
Overall, the code here is a very good starting point if you want to start messing around with your robobuilder's brain. However, the functions do a LOT of polling, which should be replaced with interrupt based timing control if you plan to implement more complicated functions.
The files can be found here. I apologise for the horrible free hosting service. Be sure you click on the "Free" tab before you hit download.
My next goal is to figure out how the recharging procedure works, and give the robot some sort of power management routine. Perhaps eventually he will be able to detect when his batteries are dying and go recharge himself.
While chasing a guinea pig under a table, I managed to cause enough vibrations for the robot to topple off and land face-first on the ground. Although this may sound both comical and adorable, I was not amused.
At first, everything seemed OK, but closer inspection revealed that one of the spanner shaped connectors had snapped, and more thorough testing revealed that one of the servos was making a grinding noise.
Disappointed, but not discouraged, I voided my warranty and opened it up to see what the problem was.
As it turns out, I had stripped some teeth of a plastic gear, which meant that the motor was spinning uselessly as the feedback loop was broken. Fortunatley - in one of the more pleasant customer experiences I have had - it turns out that the robosavvy people had included a bag of spare servo gears.
So fixing it was just a matter of unscrewing the case and feasting on the deliciousgoo inside. If a screwdriver was included in your kit, don't use it to open the servo cases! It's just a shade too big, and I ruined the tip by trying to get the screws out. Just one size smaller should do it, but be sure to push down hard against the screw so that you don't strip the head off.
Included in my kit was an instruction sheet (the backdrop of these photos), which explained how the wCK modules can be re-assembled. I don't know if this is because the expect them to need servicing at some time, or just because they had the CAD models lying around. Either way, there isn't much to the gear assembly, so don't be afraid to open one up if you are curious. After replacing the damaged gear, I simply slid the bearing back on to the drive shaft and put the case back on. At this stage, I was worried that I might have not oriented the output shaft correctly, resulting in the servo position being slightly out of phase with the desired angle. However, the wCKs must use optical encoding or something to establish their position, so after putting the case back on it just worked straight away. [UPDATE - The servos actually use a potentiometer, but the shaft is designed to only fit correctly].
So there you go - a potentially disastrous situation was averted thanks to the inclusion of some spare parts. Since nothing lasts forever, I would recommend you order from robosavvy - their service so far has been exemplary.
The Robobuilder kit is actually really easy to put together. Inspired by similarrobots, I chose to assemble the HUNO configuration.
The instructions are very easy to follow, but here are a few things that I learned which might make it easier if you are having trouble.
Firstly, whenever I build something, I assume I will make at least one mistake. This might mean undoing and re-doing several steps, so I never tighten anything down completely. This has the added advantage of making it easier to line up parts which are already attached to the assembly. Most of the wCK servos are attached to the frame using four screws, but only two are necessary to fully constrain the unit. Once I had fully tested the robot, I went back and put the other two screws in each of the servos. I was glad I took my own advice when I realised about 4 steps in that the numbers on the servos actually matter. I should have realised this earlier, since the servos are daisy chained together, so they must need to be addressed in some fashion. It is possible to reassign the ID numbers on the servo, but all of the examples and tools assume you have assembled the model as shown in the instructions. The little spanner shaped connectors have a tiny bronze threaded nut in one side of them. If the bolt you are using isn't exactly lined up with the hole, it has a tendency to push the bronze nut out of the plastic. Once out, it's really hard to get back in, so make sure that you can see right through the hole before you put the bolt in. Finally, I strongly recommend attaching the arms (steps 15 and 16) before attaching the legs (step 14). The legs are very heavy and tend to flop around while you're trying to orient the arms to put the bolt in. The arms are much lighter and won't move under their own weight.
Posts
