Welcome to the third video of my Model StorageRobot project.
In this video, I’ll talk about the interface between the storage robotand the remaining components of the project.
To reiterate, here is the “big picture”I developed in the first video of this series.
If you haven’t watched the introductoryvideo yet, I’d strongly recommend it.
In the previous video, I explained the hardwarecomponents that make up the storage robot.
In this video, I’ll be focusing on the interfacebetween the hardware and the Photon.
It’s important to get a number of aspects sortedout before starting to program either side of the interface.
There are a lot of aspects to think aboutwhen designing an interface, especially for professional system design.
Fortunately, inthis project, I’m not aiming for the levels of robustness, versatility and reliabilityrequired in a professional environment.
This is a hobby project, so I get to choose whichproblems I want to tackle and which I can ignore.
One of the first decisions when designing an interface is – do we want to build a serialor a parallel interface? For a serial communication, you break up thedata you want to transmit into individual bits and transport the bits sequentially througha single connection.
That’s usually done with the help of a specialized chip usuallycalled a UART – for Universal Asynchronous Receiver Transmitter, although many UARTsalso support synchronous communication, depending on the protocols implemented.
For parallel communication, you've got a single dedicated connection for each bit you wantto transmit.
Let’s take a look at some examples.
When you plug in a mouse, it’s likely tobe a USB device.
USB is Universal Serial Bus – the “serial“ is in the name.
For yourmonitor, you’ll use HDMI and other digital video connectors, which are serial connectionsas well.
So is FireWire.
Moving on to internal components – if youplug an new graphics card into your PC, you’ll probably be using a PCI Express slot, whichconsists of multiple serial communication channels.
For your newer and bigger hard drive,you’ll probably use SATA, Serial ATA, which again has “serial“ in its name.
To connect multiple computers, you might use an Ethernet network, which, again, is a serialconnection.
It appears that parallel communication hasalmost completely disappeared from the current technology market.
Here is an example someof you might remember – a legacy printer cable – and you can see why they have disappeared:you need huge connectors (because of the large number of pins), and you need expensive andbulky cables.
Now it looks like serial communication mightbe the way to go – however, there’s a slight problem for this project: The Robo Interfacedoes not have a UART that we could use from the ROBO Pro programming environment, andyou really wouldn’t want to construct a UART in flow diagrams.
However, we’ve gotseveral I/O lines still unused, so for this project – parallel it is.
The next thing we need to determine is thetopology and the roles in the communication.
In our case, it will always be and end-to-endconnection between exactly one Robo Interface and exactly one Photon, which simplifies thingsa lot.
Here is an – informal – example of how a communicationbetween these devices might look like.
The Photon asks, “Do you have a piece in yourinput area?“, to which the Robot responds with “Yes, I do.
“ The Photon then tellsthe Robot to pick up the piece, and after that has been done, tells it to identify itscolor.
After it learns that the new piece is red, it tells the Robot to store it ina certain location.
This is an example of a so-called master-slavecommunication.
The Photon is always the initiator, sending a command, and the Robo Interfacereplies with either an acknowledgement or – depending on the command – the informationrequested.
So what are the commands, which argumentshave to be supplied by the Photon and what responses can be expected from the Robot?The first basic command is to initialize and re-calibrate the Robot.
We might need to dothat from time to time or after some unexpected event occurred.
This command does not requireany arguments and does not produce a result.
The next command would be to check the inputslot using the photoelectric sensor, to which the Robot responds with “empty“ or “occupied“.
Then we can tell the Robot to pick up a piece from the input slot, which should normallyyield “OK“ as a response.
However, if something goes wrong or we forgot to checkthe input beforehand, the Robot might also tell us “I haven’t picked up anything“.
Usually, we would then tell the Robot to check the color of the piece it is currently holding,yielding either “empty“ or one of the three colors of pieces.
Then we can tell the Robot to navigate to one of the storage bins, identified by theircolumn A to E and their row 1 to 4, and store the piece.
Similarly, we can tell the robotto retrieve a piece, which again should yield “OK“ as a response, but occasionally mightalso yield “I haven’t picked up anything“.
Finally, we can tell the Robot to drop thepiece it is currently holding into one of the six output slots.
Since we’ve already decided to implement a parallel interface, we now need to determinethe number of bits (or lines) to encode the commands, arguments and response values.
Let’s take a look at the responses first.
The commands yield either no result, one of two or one of four possible values.
Sincewe’ve got at most four values to encode, we’ll look that up in our trusty table ofthe powers of two.
Four is two to the power of two, so we need two bits to encode theresponse values.
Similarly, we’ve got eight distinct commands,so when we look that up, eight is two to the power of three, so we need three bits to encodethe commands.
Fine so far – let’s move on to the arguments.
For the X position, we have to encode fivevalues, so two bits are not enough, we need three bits.
For the Y position with four values,two bits are sufficient.
For the output slot Z, we need three bits,but since X/Y and Z are never transmitted together, we can re-use the same lines.
This means that we need a total of five bits for the command arguments.
Combined with the3threecommand bits, we need a total of eight lines going into the Robo interface; and we’llalso need some additional transmission control lines we’ll talk about later on.
Sounds good, but – taking a closer look at the hardware – after the construction, onlyseven lines are left that can be used.
So we need to come up with a different design.
A first approach might be to transmit commandand arguments serially.
In this example, we first send the NAVB command, followed by theX position B and the Y position 3.
Similarly for the output: first send the DROPcommand, then the output slot C.
You can already see that we’ve got a variable number ofarguments to be transmitted depending on the command, and some commands don’t take argumentsat all.
In the common programming languages, thatwouldn’t be a problem at all, but – here’s our little spoilsport again – handling variable-lengthcommand sequences is surprisingly difficult in graphical programming environment likeROBO Pro, so that’s a road I’d rather not take.
Do we have a better option? Yes, we do.
For this, we’ll first changethe addressing mode of the NAVB command, combining X and Y to a single ID ranging from A1 toE4.
This specifies the position in a 5 by 4 matrix, resulting in 20 possible variationsof the NAVB command.
To encode this, we need five bits again, so apparently, we haven’tgained anything.
However, five bits encode up to 32 values.
For the variations of NAVB, we’d only use 20 command codes, so we’ve got 12 left.
To encode the six variations of DROP, we need another six codes, and the remaining six commandsdo not take arguments and so require one code each.
In total, we need 32 combined command and argument codes to represent every action wecould order, so we don’t actually need more than five bits.
This is the revised command table, containingthe commands we’ve already seen earlier, their binary representation (which will behandy in the next video) as well as the detailed specification of the response values.
Theorder of the commands is more or less random – for instance, you can see that the inputcheck was added later on.
I mentioned earlier that we need additionaltransmission control or “handshake“ lines – why? There are two additional requirementsthat we haven’t taken into consideration so far.
First, the Photon needs to know about the current state of robot.
More precisely, itneeds to know whether the Robot is able to receive and execute the next command.
The second issue is a bit more subtle: The data and command lines might be set individually- there’s no guarantee that they’ll all change levels at exactly the same time, norwill they change levels instantaneously, there might be a transition phase where the levelsare in an undefined range.
Without a clear signal, the Robot might try to interpret somenonsensical intermediate state as command and execute that.
In our case, that would be particularly bad because the command codes don’t containa checksum, so every possible value is a legal command.
So what exactly is the additional informationwe need to exchange? The Robot needs to have a way of telling thePhoton “I’m currently busy and can’t accept new commands, please wait until I’vecompleted whatever I’m currently doing“.
After that has been done and a new commandis encoded, the Photon needs to tell the Robot that the command is now ready to be read executed,and after the Robot has read the command, it needs to acknowledge it so that the Photonknows that the Robot has received the command.
To explain this communication in detail, we’lluse a so-called timing diagram.
On the left-hand side, you can see the bitsor data lines.
These are the five command bits from the Photon to the Robot and theREADY signal, and these are the lines from the Robot tothe Photon.
The result lines were originally intended to transmit a color value and aretherefore still called COL0 and COL1.
Note that BUSY is a low-active (or inverse)line, hence the horizontal line above its name.
That means that the Robot signals thatit’s busy by pulling this line down to logical zero.
We’ll see why that is useful in amoment.
In a timing diagram, the time progresses fromleft to right.
Initially, the Robot is switched off, so the BUSY line is low, signaling thatthe Robot is busy.
Well, not exactly, it’s off, but the consequence as far as the Photonis concerned is the same: The Robot is not ready to receive the next command.
When we switch the Robot on, it performs its initialization routine, which might take sometime – during that time, it still stays busy.
When it’s done initializing itself, it raisesthe BUSY line to logical 1, signaling it’s ready to accept commands.
It now waits – and keeps waiting – until somethinghappens.
That might take some time.
When the Photon relays an incoming command,it first sets the command lines – in any order; since the READY line is still low, this isallowed.
Only after the Photon is finished encodingthe command, it raises the READY line, signaling there’s a command waiting to be executed.
The READY line is also a promise to keep the command bits stable until READY is turnedoff again.
The Robot now reads and interprets the commandbits, and then raises its ACK line to signal it has read and buffered the command codeand is ready to execute the command.
This causes Photon to drop its READY signal,at which point the Robot can no longer rely on the command bits being stable.
Then the Robot drops its ACK and BUSY lines,signaling it’s executing the command.
For the most part, that involves mechanicalaction, so that might take some time.
If the command yields a result, the robotwill then set COL bits, and then raise the BUSY signal.
Remember, the signal is low-active,so that means “I’m no longer busy.
“ That signal is also a promise to keep theCOL bits stable for readout.
After that, the cycle repeats whenever thenext command is issued.
To summarize, we’ve got the basic layoutspecified as an end-to-end communication with the Photon in the master role and the RoboInterface as a slave device, and we’ll use a parallel interface.
The command set consists of 32 command codes that include the argument values.
We need 5+1 bits to transmit commands to the Robo Interface and 2+2 bits to transmit theresults to the Photon.
We’ll be using an asynchronous communicationprotocol – so no clock signal – with three transmission control lines, following thetiming diagram we’ve just seen.
That means we’re good to go – in the nextvideo, I’ll describe the implementation of the hardware control software using ROBOPro.
If you’re interested in the progress ofthis project, there are a couple of ways to keep up to date.
I’ve created a Youtubeplaylist you might want to follow, but of course you’re also welcome to follow myentire Youtube channel.
I’ll also be blogging about this on the SAP community network (SCN)- the link is in the description.
You’ll find the articles in my personal blog as well.
If you have any questions, suggestions or would like to leave any other kind of comment,feel free to use any of these channels to get in touch – I’m looking forward to it.
Thank you for watching, and have a nice day.