The IC in post #75 is a 4017 Decade Counter (or also known as a Johnson Counter) here is a quick tutorial on the IC and its functions >> http://www.doctronics.co.uk/4017.htm



You would "simulate" the hardware on a solderless breadboard if you have one.... or redraw the whole thing in a different application that can also simulate it....

Usually I will draw up my schematic in eagle, then I will build the circuit on a breadboard which I include ICSP connections for my Pickit2/3 and then start on the software side, so I can test and debug hardware and software at the same time, so I can see if I may need to move an I/O to another pin, etc.

After all the software, and hardware debugging is done, then I will update the schematic with the changes (if I have not done so, usually I update it as I make changes to the circuit on the breadboard) then I will layout the PCB and make them from the final version of the schematic.

I will do just that!!! test it on breadboard and degug both hard and software...or will do straight PCB and will just debug the software...The PCB layout will be done from Eagle....correct? yes! but which *software* can handle this simulation

BTW, my chess engine is ready BUT I have not tested it yet...will do that on friday using two computers...one for the chess simulator and the other one for the chess engine! I will discuss it with you guyz for tips on how to implement the coms protocol...into the PIC


Thanks so much!

 

Can someone please address post#77 on the paragraph right before BTW,...

it about using another pic to control the robot changes on the chessboard!

thanks!

 

Can someone please address post#77 on the paragraph right before BTW,...

it about using another pic to control the robot changes on the chessboard!

thanks!

In my opinion, a larger pic (40 pin one) can handle all those tasks just by its self, you can use that to control the arm, monitor the board and communicate with the PC..... something like a PIC16F887 would do.

 

In my opinion, a larger pic (40 pin one) can handle all those tasks just by its self, you can use that to control the arm, monitor the board and communicate with the PC..... something like a PIC16F887 would do.

Sounds good! I have a brand new PIC16F877 PDIP never used before...So I don't need a PIC18F series for this project, huh? PIC16F877 can handle errthang!! PIC16F877 has only 8kb program memory and 368 bytes SRAM, is that enough!?

it ok! but to be on the safe side I'll order 40 pins PIC18F46K20...

Thanks again!

 

well...it about time to start with the programming part as it might take some time to finish up...

In a few hours I will attach my 'chess simulator' and 'chess application' and explain the communication protocol! I have not tested it yet myself (can't find time but I will) ...

The reason I post them is for *Big Boyz* to have a look and even try it if they can/or have time...so they can study/observe te behaviour of the chess engine and comms protocol so they can have idea how to implement it to the PIC mcu...so when I start programming in a week time...they will help me easily ...I also have ideas...

They need to be tested using 2 PCs...but I i'll remove that by end f day...it only for BIg Boy to save the 2 apps!

thanks!

 

Alright!

It time to do real programming and all the Big boyz are invited!

Attached is a little simulation to show you how the communication protocol works! The simulator (electronics chessboard) sends a '5 digit' number to the PC (Chess engine) indicating the piece that just been moved and the chess engine also sends back its counter move by also sending a '5 digit' number.

The '5 digit' number specifies the following:

- 1st digit: specifies the piece type (black or white) that has been moved.
1 = black and 2 = white.

- 2nd and 3rd digits: specifies the start location (XY), ie where the piece has been moved FROM (2nd digit= X coordinate; 3rd digit= Y coordinate).

- 4th and 5th digits: specifies the the end location (XY), ie where the piece has been moved TO (4th digit= X coordinate; 5th digit= Y coordinate).

Note: 1 <= X <= 8 and 1 <= Y <= 8

Example to move the 'white pawn' from B2 to B4 the following needs to be sent:'22224' easy isn'it? and after the chess engine has calculated its counter move it will send back its '5 digit' number to the simulator (or chessboard-mcu) specifying where it has moved! AND THIS WILL BE USED TO INSTRUCT THE ROBOTIC ARM.

But now the chess engine can play with black or white piece based on what the simulator has chosen, ie if the simulator starts with a 'white' piece then the chess engine will play with 'black' pieces or if the simulatorr starts with a 'black' piece' the engine will play with 'white' pieces.

So the trick for the microcontroller will be to have its 1st digit pre-defined...I mean this:

We can make a constraint/rule whatever you call that to make things easier...like the microcontroller (human being) will only play with WHITE pieces meaning that in its memory, the first digit will ALWAYS be '2' and the human being will ALWAYS start first...Easy right!

-----------------------------------------------------------------------
In the attachment 'sim1' it can be seen that the simulator sends '22224' and the white pawn is moved from B2 to B4. And the chess app acknowledge the received move!! look on top "command received from
chess machine"

In the attachment 'sim2'it can be seen that chess engine has moved the black piece (actually red...lol will change that into black later but not important for now!) from location E7 to E6 and has sent the command '15756'. please look at simulator 'last move'
-----------------------------------------------------------------------
in sim3 simulator sent command '27273' to move white pawn from G2 to G3' and chess engine acknowledged and you can see piece moved on the chess board.

And this goes on and on and on....

Please ask me if something is not clear!!

I will post soon the .inc file for it based on the schematics design

Thanks!

[edited] Attachment removed! but can be put back if needed!

 

It's a good start. The simulator talks to the chess engine and then calculates the angles of the servos to send to the robot and receives the piece positions from the board.
Next step would be deciding the protocol to communicate with the arm and a calibration program where you can control the position of the arm to drive it to the 4 corners, so the simulator knows where they are, then translating grid positions to arm movements.

 

It's a good start. The simulator talks to the chess engine and then calculates the angles of the servos to send to the robot and receives the piece positions from the board.

Wait wait wait...one little clarification! the simulator was created just to test the functionality of the chess engine-electronics chessboard comms protocol! Now I know that the comms works perfectly so the simulator is out now! and will be replaced by the PIC16F877 are you with me!? I am saying this coz you sound like I am still going to make use of the simulator...No!!

The highlighted quote confuses me a little! the simulator makes no calculation! one just enter the '5 digit' number to make a move then click 'send' button then after Chess engine has decided on its counter move it send '5 digit' number as well to the microcontroller (simulator in this case) and this number actually tells the robotic arm where to move the piece for the chess engine!!

Next step would be deciding the protocol to communicate with the arm and a calibration program where you can control the position of the arm to drive it to the 4 corners, so the simulator knows where they are, then translating grid positions to arm movements.

Again the simulator is a replacement of the electronics chessboard (mcu)

I think the first step is to be able to write a code that sends '5 digit' number to the PC (chess engine) based on the scanning of the board

second step would be how to translate the received '5 digit' into a command that instructs the arm to move in a certain position as you mentioned!

I think this would be much easier to write a PC program that translate the '5digit' number sent by the chess engine into a corresponding arm movement...

for instance in the above attachment 'sim2' the chess engine sent the command '15756' to inform the microcontroller that the arm must move the black pawn from location E7 to E6.

thanks!

 

the chess engine and the simulator was tested using two different PCs but here I just showed the simulation using one PC and have used the virtual serial port emulator to connect the two different applications in the same PC!

Maybe the chess application should include a function that translates its '5digit' number into arm movement! (Not the simulator) and then send that to the microcontroller as I assume that will be to commplex to implement that into int PIC!!

Simulator like I said was just to test functionality before writing code on the PIC...I also made it to proove to my examiner that my stuff works!

 

I think the first step is to be able to write a code that sends '5 digit' number to the PC (chess engine) based on the scanning of the board

second step would be how to translate the received '5 digit' into a command that instructs the arm to move in a certain position as you mentioned!

I think this would be much easier to write a PC program that translate the '5digit' number sent by the chess engine into a corresponding arm movement...

for instance in the above attachment 'sim2' the chess engine sent the command '15756' to inform the microcontroller that the arm must move the black pawn from location E7 to E6.

thanks!

No translation is really needed, because once the programming of the arm controls are done, all you would have to do is have a "Move Arm" function (in the UC) that will take the last 4 digits of the 5 digit that was sent and pass those as an arguement to the "Move Arm" function, the ARM does not need to know that it is white or black, all it needs to know is where to pick up an item and where to drop it off at, since all the arm has to know is where these positions are, which will be all done during the initial arm calibration routine to set it up for the dimensions of the board.

 

It's got to be much easier to do as much calculation as possible in the PC. I'm sure it's possible to do it all in the PIC but it would take longer to code and the overall result would be the same.

 

No translation is really needed, because once the programming of the arm controls are done, all you would have to do is have a "Move Arm" function (in the UC) that will take the last 4 digits of the 5 digit that was sent and pass those as an arguement to the "Move Arm" function, the ARM does not need to know that it is white or black, all it needs to know is where to pick up an item and where to drop it off at, since all the arm has to know is where these positions are, which will be all done during the initial arm calibration routine to set it up for the dimensions of the board.

Everything written is 150% correct!! Only last 4 digit is needed for the arm as you explained...but actually when we talked about translation we meant that 'move arm' function in the PIC that takes those 4 digits as arguments...

So now I think exact dimensions of the board are needed for the calibration you mentioned (I already have the wooden board it a 12 b12 inch) but I will do all the measurements and post it in a schematics!!!

I mean outer border, inner border (arm workspace), individual square size, the board stand height. I think that's is for the board then all arm dimensions will be needed. that's about it for the arm calibration I think!

So basically two routines needed for arm: initial callibration routine and move arm routine. correct?

 

It's got to be much easier to do as much calculation as possible in the PC. I'm sure it's possible to do it all in the PIC but it would take longer to code and the overall result would be the same.

First I think we need to come up with the algorithm that will implement the 'move arm' function! based on that an estimate of whether or not the PIC can handle that easily...I am talking about the number of instruction cycles, clock speed and program memory here!

that's why I asked sometimes back if PIC16F877 cab handle that if not PIC18F46k20 is my second choice...

Unless we make a table of 64 inputs that actually corresponds to all possible locations 0n the board and have our PC program that does the move arm function and outputs 64 commands/whatever you call that then in the PIC we going to have 2 tables: input (chess engine sent move) and output (move arm function output) then have some kind of mapping....

anyways...that just a thought! sorry if that sound stupid!

but I think having that move arm routine inside PIC is better...but algorith first is needed!

 

Here's a couple of calculations, there's another one for the angle of the base servo and a few more for the adjustment needed for calibration. It's entirely possible to do them in a 16F877, especially because they don't have to be done very often. It might actually take a second or more, it isn't easy for the PIC, and to me it doesn't make much sense when it's connected to a PC that can do millions of floating point calculations per second.
The calibration is needed because hobby servos aren't precision made, if you send pulses that are calculated to move them 90 degrees, they might only move 85 degrees or they might move 95 degrees. Once set up they should be pretty accurate.
Also there is the alignment of the joints and board, it doesn't take much difference to put the end of the arm in the wrong place.

 

Here's a couple of calculations, there's another one for the angle of the base servo and a few more for the adjustment needed for calibration. It's entirely possible to do them in a 16F877, especially because they don't have to be done very often. It might actually take a second or more, it isn't easy for the PIC, and to me it doesn't make much sense when it's connected to a PC that can do millions of floating point calculations per second.

Alright! this calculation (move arm) can then be added in the chess engine, ie instead of sending the '5 digit' to the microcontroller...the chess engine will have an extra function that extracts the '4digit' as Bmorse said and give it as argument to the 'move arm' function and send that output (arm movement) to the microcontroller for the arm! How about that??
But then the complete description of that routine is needed prior implementing!

The calibration is needed because hobby servos aren't precision made, if you send pulses that are calculated to move them 90 degrees, they might only move 85 degrees or they might move 95 degrees. Once set up they should be pretty accurate.

But the calibration routine should be done by PIC in the initialization, correct?

The attachment is good and very basic!! and so far:
- b is known: 3.3cm
- a is still UNknown
- square size (actually one side length): 3.6cm
- chessboard in on its stand of 5cm high
- x and y equations are correct!
- cos (c), I guess c is the angle at joint2 (on top of joint1); D = linkage2; E = linkage3 as described in the very first arm scketch and D=E.
- L on the leftside is the top view of the arm and the rightside shows the side view.

Also there is the alignment of the joints and board, it doesn't take much difference to put the end of the arm in the wrong place.

How come? Initially I thought of having the arm and the chessboard separate from each other...but I think it would be better and easier if the chessboard and arm are connected to each other...ie we'll have the arm screwed/glued whatever with the chessboard!!! they will always be moved together

What other calculations are needed for the calibration??? can you describe the full calibration required!?

Thanks so much!

 

Yes, c is the angle between linkage2 and the horizontal. It makes sense to have linkage 2 and 3 the same length so that when joint 3 is in it's highest position (pieces nearest the arm) joints 2 and 4 will be close together.
I'll have to have a bit of a think about the calibration.

 

OK! I think a complete algorithm/pseudo code needs to be described for the 'calibration' and the 'move arm' in order to implement it faster...

Just like one of my signature says..."Algorith first, Code second"
I am thinking about it too...

 

I did a little research and found this link: http://borglabs.com/blog/calibrating-robot-arm and there are other links in there! looks like Ms Excel is going to be our friend for the geometry calculation...unfortunately can't read it now...

And apparently it possible to simulate and visualize the arm position and angle with Excel!

[edited] sound complicated...

 

This is just the initial .inc file...will update it as I go...but I have been trying to set the clock for 20 MHz external as on the schematics but Can't see on the datasheet where they talk about setting up the clock!


So far the .inc file just define the pins...
Any guidance on that...

thanks

[edited] .inc file removed

 

This is just the initial .inc file...will update it as I go...but I have been trying to set the clock for 20 MHz external as on the schematics but Can't see on the datasheet where they talk about setting up the clock!


So far the .inc file just define the pins...
Any guidance on that...

thanks

Personally I prefer:
servo3 equ 0
and in the code:
PORTC, servo3

rather than:
#define servo3 PORTC, 0
and in the code:
servo3

purely because if you hover the mouse over the first one you can tell what it is, but if you use the second version the IDE won't tell you so you have to scroll back up to check the define section.
Also should all the SFRs be in capitals?
The external clock should be in the config word, check that section of the datasheet or possibly the 16F877.inc file.