Why couldn’t an Atom receive the commands from RoboRealm, interpret them, and send commands to the SSC-32 to control the servos?
The Atom can do serial input.
The Atom can process input.
The Atom can send commands to the SSC-32.
Wouldn’t this work once one knows what format the commands from RoboRealm are and what each command is supposed to do with the SSC-32?
8-Dale
Roborealm has a serial system that allow you to just type whatever you want in the text input. It wouldnt be able to run a complete sequence though.
The mods Laurent has made are ideal, on board Sequences and Sockets are a brilliant step in the right direction, not just for roborealm but for other applications as well…
Nice One…
To be honest, its possible that whatever roborealm do implement, it may not be as powerful as what Laurent is offering…
Whens the rollout of 1.03…Nag Nag Nag… 
I figured this although I still have not actually tried to do anything with RoboRealm yet. However, if you can control the data RoboRealm sends to the SSC-32, then there shouldn’t be any reason the commands could be formatted for the Atom to take and interrpret.
Yes indeed, and it also brings up the need for security so one can be sure only those who should be connecting to their do so SEQ can and only from specific locations (i.e. from a specific web page script).
OK, it’s time for me to dig into RoboRealm and find out exactly how it controls devices… 
8-Dale
My thinking is, the command set for SSC-32 and the socket server in SEQ are defined, and constant. The command structure for talking to an Atom are whatever the builder/programmer think up. You can see the difficulty in supporting this. Bear in mind I do not know how RoboRealm works. If it has the ability to let the user define the commands it can send then it might be a moot point. 
This is true. The beauty of microcontrollers is they can do pretty much whatever you want them to do if you have chosen the correct part for your application.
I am browsing through the “Control” section in RoboRealm where the device controls are. There is what appears to be a generic “Serial” control which has text boxes where you can enter stuff to send or receive. Using this, it looks like one could define their own command protocol with any device that has a standard serial port.
I am going to have to fiddle with this to be sure it works as I think it does. I happen to have an Atom PRO here to work with, and a webcam to give RoboRealm image input. If the generic Serial control works like I think it does, I should be able to have RoboRealm interact with the Atom PRO.
8-Dale
The SSC will work because i has an event handler that knows the defined sequences of all the commands and interprets then when it receives.
What the Atom will need and I’m assuming the programmer can implement (never seen one so not certain here) is an event listener that will read any incoming comms and react.
As you say RobotDude, the Atom is an open book to be programmed as required. So each of us using the Atom will come up with our own command sequence in much the same way as the protocol for the SSC was defined…
I would suggest that for a soccerbot, I might need a command (BALL_AT) that sends me coordinates, linuxguy might implement his as (TARGET_AT) with coordinates, Someones bound to try and implement as X,Y,Z coz they want to try and play volleys… but each is going to have to implement their own.
Again… I think…
Robo Realm sends commands via the serial port to a supported hardware, in this case the SSC-32. You can set up what happens and when, based on variables chosen from the SSC-32 module. In the setup dialog, there are list boxes with lots of variables listed. One example is the COG_X variable; it takes the value and sends pulse commands to the servo to move in the x axis.
Another variable one could use is the COG_AREA. What this does is check the number of pixels in the COG box. The closer the object, the more pixels are going to be in the box, the further the object, the smaller amount of pixels. This can cause robo realm to send a command to the SSC-32 to move servos closer to the object to maintain the set amount of area (distance) depending on it’s actual distance from the camera. I do not know the exact setup for this but this should gave a quick peek as to what can be done.
Hi SN96
We’ve been playing with that, its in the adjacent thread. Roborealm is limited on what it can do with serial, there can only be one instance os serial in any filter combination therefore you can either build a long variable to send as your command or just issue one single command.
I know its a bit off thread but someone mentioned the Atom and other processors are used a lot to either directly control or interface to the SSC. We just pointed out that the programmer could incorporate some extra commands into a comm stream handler to deal with either comms, sockets or even the API.
I’ve done an API example in the adjacent thread (Id give you a link but I don’t know how) which does exaclty what you said.
I use COG_WEIGHT to determine there is an object of sufficient size in view to be the ball and then used COG_X and COG_Y to decide which way to turn ( or not if its sufficiently centred)
I don’t understand what you are saying. You can do two things simutaniously in RoboRealm. I have an example here:
Yes agreed, but for the serial Control there can only ever be one open at a time.
<If Condition 1 then >
Serial
<If Condition 2 then>
Serial
Would work on the first pass if condition 1 was met but if on the next pass condition 2 was met then the second instance of Serial would fail because instance 1 already has control of the serial port
The only way I found of achieving it was
< If Condition 1 then>
Create Variable String for sending
< end if>
< If condition 2 then>
Create variable string for sending
This worked but because the loops can be very quick the data was getting sent before the previous sequence had time to finish.
I did have a quick look for a wait command but didnt spot anything obvious
Ah ha! now I see what you mean. That second example is the way to go, it is closer to Finite State Machine programming, also known as FSM.
I hate state machines. Had to work on one that had over 5000 possible states. It was second hand work because the guy left so I was lost for weeks. There were hard-coded decisions in the engine that meant if we added any new possible states to the Oracle database, the whole thing failed.
Scrapped it in the end and started again.
Arrggh done it again, Hijacked the thread for a moan…
