- The button pad: I tried to follow the copper traces as good as I could (some are covered by the rubber knobs). It seems, that each button has 1 seperate pin, but all share one common pin. See the following picture, where I marked the buttons the the corresponding pins:
Connect the "GND" pin with ground and the other pins with digital input pins of the Arduino. Be sure to use the internal pullup resistor via
pinMode(pin, INPUT_PULLUP). You can then check the button state for each pin with
- LCD and motors: This one is more complex. First see the picture of the LCD/motor board:
1 is an extra microcontroller, that handles the LCD directly over the lines marked with 4. 2 and 3 are brushed DC motor drivers, to be exactly: 2 (part number MX1805) is a dual H-brigde driver and 3 (part number MX612) is a single H-bridge driver. So enough drivers to drive the 3 DC motors in both directions. The 5 lines, that come from the main board of the claw, seem to run under the driver board and then to the microcontroller. Two of them must be the power supply (5V and ground). It seems that the green wire is ground. Red seems to be 5V. That leaves us with 3 wires, that come directly from the main microcontroller. Without analysing the signals, that run through these lines during operation, it is not possible for me to say, how they are used.
So I think you have 2 possible ways to go:
- Reuse the old LCD/motor board: In this case you will have to analyse the signaling through the three mentioned lines and do the same with the Arduino. That is possible, though difficult especially for beginners. You will need an oscilloscope or a logic analyser for this (They are extremely useful tools, so it might be good to buy that anyway).
- Build the electronics yourself: You can buy relatively cheap LCD modules, which are interfaced via I2C or SPI and where there are ready to go libraries for Arduino. For the motors you can either desolder the old motor drivers, buy your own or build your own with MOSFETs. The important term here is "H-bridge", which means the way in that the MOSFETs are arranged. There are many tutorials how to use H-bridges with motors on the web. If you buy driver chips, be sure to use those with MOSFETs, which are way more efficient than older types.
The second type means doing more yourself, but you will not have to reverse engineer the old electronics, so I think, that would be easier. Each task is simple for itself and you can solve them one by one. The first option on the contrary will leave you with the one relatively difficult task of reverse engineering the communication protocol.
I have thought of 2 basic possibilities for the 3 lines from the main controller to the secondary controller.
They might be data lines, where some kind of communication protocol is transmitted. Most likely that would be I2C, UART or SPI.
I2C is a 2 wire interface, so the third line might be a simple digital line (maybe for triggering something). For I2C both lines are HIGH (at Vcc level) when idle. You can check that for the lines with a simple multimeter. Also you can use an Arduino and try to attach it's I2C hardware interface to it. The Arduino would be the slave device and needs an address. Here you would have to test every address, until you find one that works (There are 127 addresses in normal mode). You would have to test a lot for this (also rotating the wires, as you don't know, which one could be which I2C line), and it's not guaranteed to work, even if it uses I2C.
SPI is a 3 wire interface (clock, MasterInSlaveOut, MasterOutSlaveIn). Also for SPI every chip has an extra line for chip select. Since here we only have one chip, that would be hardwired. Connect the Arduino's SPI interface to the 3 lines and test, if you can get any data from it with any permutation of line connections.
UART uses 2 wires (RX and TX). You can hock up the RX line of your Arduino to any of the lines and try to get any valid data there. You would have to test all the common baudrates and hope, that they don't use uncommon ones. Maybe it is simpler to instead hockup the TX pin to the lines. That would connect the receiving pin of the UART-USB transmitter, so that you can directly see the data at the PC (some serial terminal programs can guess the correct baudrate). In this case be sure, that the Arduino will not send data over Serial at any time, because that can destroy things. Best remove the microcontroller (if you have a removable one) or load a sketch without the
Serial.begin() or any other Serial statement.
They might have decided during design, that the LCD does not need data from the controller, but should only display information from the motors. You can check for that a bit. If the LCD shows any information not regarding the motors but the input from the controller, this point is not applicable. If not, the three lines might be simple PWM signals for the three motors, with a duty cycle of 50% meaning stop. To test this, you can attach one LED to each line (including a current limiting resistor). The other end of the LED goes to ground. When using the buttons to control the claw, you might see the LEDs dimming or lighting up exactly for the motors powered (1 specific LED for 1 specific motor). Don't forget the current limiting resistor for each LED, or you might fry the controllers pins.
That's about what I can think of to reverse engineer this without oscilloscope or logic analyzer. Since neither of this seems very easy for a beginner, maybe you should ask your professor for help. He might be able to give you hints or at least an oscilloscope to work with (most universities should have these). If you get a good oscilloscope image from the lines during transmission, you can ask a question to identify the used protocol.