You know I bought a Service Droid from Dagu, right? I wrote about assembling the kit here: https://www.robotshop.com/letsmakerobots/node/39518
December 15, 2013.
I had a busy week and not much time to work on the robot, but over the weekend I started to steal some time to add the missing bits. First, I mounted an Ultrasonic sensor at the end of the "neck" piece. And an IR remote sensor. Then I soldered the parts to a second uBotino board (v3 this time, no more v2 boards). but left out the motor driver. All that was easy. Now the hard stuff started.
When you're "borowing" someone else's code, it never works right for you. That's because the hardware is most likely different. So you have to comb through the code and see what's different and fix it. Sure, it takes less time than writing your code from scratch, but you still have to work some time to get it working. As you already guessed, I am working on OddBot's code (from his OB1 robot). Fortunatelly, I have an ideea of what I'm doing, otherwise I would give up and start clean. Even though it's well commented, there are ways to code stuff more efficient that I wasn't exposed to, so I had a bit of a hard time to figure out what is going on. But let me tell you what I did.
First, I have the encoders hooked to different pins. so I thought, just change the pins and done, right? Well, not really, no. Because OddBot used direct bit manipulations to deal with the encoders. It's faster and easier. Ok, then what do I need to do? He was using the first 4 analog pins, which are mapped on Port C on the ATmega328. I wanted to use the digital pins no. 2,3,4 and 13, which are mapped on Port D and Port B. Well, too complicated. I thought about using the digital pin 1, but that is also used as a Tx pin by the serial interface, which configures it as an output. To be on the safe side, I decided to use pins 0,2,3,4. Here's OddBot's code:
encnew=PINC&B00001111;
and here's my mod:
encnew=PIND&B00011101;
Then, my motors are on different pins and they use Timer 0 and not Timer 1 like in OddBot's code, so I eliminated the Timer1 settings, because I can't change them for Timer 0, which is also used for Millis.
That was about it with the code for the Mini Driver. Now on to the code for the IR remote. OddBot used a Spider controller, so all his servos are on different pins than on my uBotino. So I changed the pins for the servos in 2 locations in the code. At first, I though to re-arange the servos in the array, but then I realized that it would break the code in other locations where the servos are referenced by location in that array. Next was the remote codes. I turned off the code that was executing the commands and just printed on the terminal window the codes for all the buttons, then changed them accordingly in the code. Then I started testing the commands with the servos. Arm select, rotate wrist, open/close the pincer and sweeper. Pan, tilt, all good. On to the motors. Press Forward, treads turn right, slowly. Press Reverse, treads turn left, high speed. Press Left, treads go backwards fast. Press Right, treads go forward slow. What the heck is going on?
First, one motor is reversed. But which one? I reversed the connector for one of the motors and then both were going backward insted of forward. So I reversed them both, which fised the first problem. Now, the motors were going slow forward but fast backward. I fugured it has to be something in the software, so I started digging. Nothing seemed to cause such a behaviour. Then I remembered. My boards use inverse PWM for reverse. So I added a check if speed was negative, make pwm equal 255 minus pwm. Basically, that makes max speed = 0 and min speed (stopped) = 255. And set the direction pin accordingly, 0 for direct pwm, 1 for inverse pwm. Done! Now my robot was driving correctly, albeit slow. Why the heck was it slow? Well, because you're supposed to press the number buttons on the remote to set the speed higher or lower. Or, just keep the Forward button pressed until the robot accelerates to the max speed.
Now that we're driving, let's test the arms by picking up some toys. I found a stray toy I wanted to get back to it's box and drove the robot there. Lowered the right arm and opened the gripper. Advanced a bit and then closed the gripper. I lifted the toy and headed to the box to drop it. Arriving at the box, I found out that the gripper would not open to let the toy fall. What ever I tried, it did not move. I turned the robot off and manually opened the gripper. Then I turned the robot back on and the servos centered, less the gripper, which remained open. I could feel little resistance trying to move it manually, but the servo would not hold the position. That means burned electronics inside the servo. I opened up the case and the smell made it clear. Fortunatelly, I have some mini servos with broken gears and an identical board inside. So I replaced the board in the Black Duck servo, tested it fine outside the gripper, then I put the gripper back together and tested again. No move... Oh boy, burnt again? But this time I had no toys in the gripper. Hmm, something's fishy. I don't know what yet, but I think I'm gonna replace that servo with a slightly bigger one that I have. I just need to enlarge the hole a bit longways. But I'll do it some other day, now I'm too tired.
I didn't get a chanse to take pictures yet, let alone a video. But as soon the robot works, I promise I'll do it. Cheers!