Introducing The 3Robot
Introducing The 3Robot - Successor to the Novag 2Robot
UPDATE: The 3Robot is now finished: https://www.chess.com/blog/chrislamuk/the-3robot-chess-computer
If you haven't already, please read my blog "Inside the Novag 2Robot" which will introduce you to the robot arm, and the terminology used here:
https://www.chess.com/blog/chrislamuk/inside-the-novag-2robot
Introduction
As the title suggests this blog brings good news about the future of my old and creaking Novag 2Robot... since my "Inside the Novag 2Robot" blog I have decided to completely gut the 2Robot and replace everything electronic, not just the arm controller but also the chess computer, with an Arduino. This might seem radical or even insane but hopefully it will make sense as you read on 
I had already written a detailed blog on the repairs I did on my 2Robot but given my decision it now seems redundant and not worth sharing but I will quickly summarise the details.
My 2Robot Repairs
Recently I bought a Novag 2Robot on eBay for about £100, sold for spares in a non-working state. It had all the original packaging and manual, and the computer looked in good condition, barely used. But like many 2Robots it had stopped working. The seller said it was a friction problem so I was confident it could be fixed. It seemed the motor that opens and closes the fingers was no longer able to do so... but I got it working by reducing the friction between the fingers and the cam collar and reducing the spring tension in the fingers.
I also noticed the elbow motor was moving very slowly (or not at all) when retracting the lower arm which resulted in an arm error. Here's a video of my 2Robot's faulty arm.
Using a multimeter I found the motor was only getting 2.3V instead of 6V... when moving forward it was 5.3V which is still short of 6V; the shoulder motor read 5.8V in one direction and 5.3V in the other. In addition the lower arm occasionally moved forward instead of retracting, giving an error. All this led me to the conclusion that there was a serious fault with the motor controller, probably with the H-bridges... perhaps that's why the fingers stopped gripping. So I had the option of leaving it as it was or replacing the arm controller with a new computer.
The Birth of The 3Robot
Everything electrical was removed from the 2Robot arm and computer base. Perhaps some components could be salvaged. The LCD alone had twenty wires coming from it, the board matrix sixteen and the button keypad ten. I had to keep in mind the number of inputs as this affected equipment choices. So I decided the LCD had to go... a modern LCD display only needs two lines. I removed and tested the encoding sensors but couldn't get them to work so I found some replacements which after some sawing and sanding fitted well enough. They are also Arduino-friendly in the sense they are plug and play and don't need any additional parts like resistors.
Space inside the arm was very limited even with the old PCB removed so any decisions concerning wiring needed to be made with care. I started off with all 24 AWG wire but soon realised it was not going to all fit. The skinniest wire (e.g. 30 AWG) is preferred for most low current wiring with thicker 24 AWG for power and GND. So after lots of cutting and soldering the wires sat through shoulder pillar and out under the computer base, ready for the computer.
The Arduino Mega
My computer of choice was the Arduino Mega (a DFRobot clone actually) with expanded RAM, flash storage and extra I/O pins (54 in total) over the smaller popular Uno. A quick count of the inputs and outputs (8 for motors, 4 encoders, 16 for board matrix, 10 for button keypad, 4 hand switches, 2 LCD display, 1 speaker = 45) suggested the Mega was ideal. The Arduino is a very simple computer sometimes called a microcontroller... it has some RAM but that's about it... no operating system, it can only do one task at a time - contrast this to, say, the Raspberry Pi which is a "proper" computer running Linux. But microcontrollers do what they do extremely well, namely, monitor inputs and determine outputs. In addition I needed a motor board between the Arduino and the four motors and the DFRobot Quad DC Motor Driver Shield was perfect as it can plug on top on the Mega. Each motor is then controlled by two lines... a digital line for direction and a PWM line to vary the speed. A 6V battery pack will provide power for the motors.
Once the Arduino was wired up it was time to start coding and getting the arm moving... the fun bit! Initial code was to make sure the encoders behaved as expected, making the arms move to their limits (START position) successfully and counting the slotted discs reliably.
The new sensor photocells didn't quite sit where the old ones did... this doesn't matter for the angle sensors but does for the limit sensors... the elbow now hits the limit too late and clatters into the upper arm... so I had to remove the plastic cam and refit "one click" off (if you get what I mean...) but that meant the elbow now hit the limit too early... so I was forced to sand a bit off the plastic cam so that the elbow was nicely tucked in when it hit the limit. The shoulder cam I also moved... it did hit the limit early but not so much you would notice.
Also the hand motors and switches were tested. I fitted a little joystick to move the arm around to assist early testing.
Arm Movement
At this point the arm was either stationary or moving at full speed, full speed being all 6V. However we can vary the motor speed and slow down the arm as it reaches its destination to avoid overshooting which ought to improve accuracy when moving to squares. So I played around with different options... I tried moving both lower and upper arms simultaneously to get to a square but it looked clumsy... so I reverted to the original 2Robot method of moving the upper arm first followed by the lower arm (the 2Robot does start moving the lower arm just before the upper arm comes to a standstill, a pretty touch!). However moving both arms at once when returning to the START position looked fine, as with the 2Robot. In addition I didn't like the constant full speed motion so I coded a nice smooth sine-like movement where the arm would start at minimum speed (about 3V) arcing up to max speed halfway before falling gently back to minimum speed as it neared its destination. This gave the arm a more graceful movement which was pleasant to watch. I also got the arm to return to START in this fashion. For shorter distances the arm moved at a constant minimum speed.
The hand movement was simpler... turn on a motor until a switch was activated. It was fine to run the motors at half speed.
Timeouts and range checks
By trial and error I found the more checks the better. The arm did some creepy things with my early buggy code like go backwards beyond their limits, and so numerous checks are now in place. Timeouts are important to protect the motors and gears. With the hand the down motion timeout is particularly important in case the fingers collide with the top of a rook and neither gave way. Ditto the closing motion of the fingers in case the piece gets caught between two fingers. Arms may bash against walls and they too have timeouts and angle checking.
Arm Reassembly
Once I was happy the arm was working reliably I had to put the arm lid back on. This sounds trivial but I'd been dreading this moment for some time... it was quite a struggle to squish all the wires into the arm without impinging on rotating discs and cams. I had to tape some of the wires to run along the underside of the lid. Eventually the lid did screw back on ok and the entire arm was reassembled. This was an important milestone and I could now start calibrating the arm.
Board Calibration
All 96 squares (64 on the board and 32 on the car park) needed to be mapped to elbow and shoulder angles. When I say angles I mean the number of slots (which I call "angle ticks" or aticks) counted to reach a square. There are roughly 500 aticks per 90 degrees. I looked at whether there was a short cut with some fancy trigonometry that would help determine all the elbow and shoulder angles but gave up (I may return to this later... I got in the ball park but was not accurate enough). So I mapped all 96 squares manually with the help of the joystick but it was hardly fun but there was some symmetry which helped, i.e. the elbow angles left and right of the vertical middle line (between the d and e files) were the same on both sides. But it did get me thinking how the old 2Robot did its mapping (hardcoded or formulaic?) and how its calibration process of the a8 and h1 squares fitted into the process. I appreciate that if I were ever to service the arm again I may have to recalibrate all the squares... or maybe I could just add a x-y offset? We shall see.
The mapping was eventually finished and I thought a nice way to celebrate would be for The 3Robot to play the Opera Game.
The Next Step
With The 3Robot arm now working I needed to find a chess engine. The original plan was to buy a Raspberry Pi 4 and use Stockfish with the Pi and Arduino talking to each other. But then I saw that someone had written a chess engine for the Arduino Mega for use with a small touchscreen. What luck... it's quite possibly the only Arduino chess engine in the world. His project is worth a quick look and can be found here:
https://www.hackster.io/Sergey_Urusov/arduino-mega-chess-ii-b2e599
So the plan now is to take that code and strip out all the touchscreen stuff and get the chess code into a state where I can use it with the arm. Initially I'll type my moves into the computer but will integrate the board matrix soon after. Hopefully by the next blog I will be playing chess against The 3Robot using chess pieces and the board!
Thanks for reading and bye for now
PART TWO
How the 3Robot was completed:
https://www.chess.com/blog/chrislamuk/the-3robot-chess-computer
