Robot Control Skype Plugin - About 40% Done

DiablodeMorte · 2008-01-11 04:45

Hello everybody,
I have again gotten back into "webcontrolled" robotics and this time I've got a different aproach. Much of the time spent on my other web controlled robotics projects was spent not on the robot, but on the control system. I have decided that this is the wrong way to go. Because I spent so much time coding the actual interaction with the server I've decided to "piggyback" my application onto a preexisting network system: Skype. For those of you that don't know what Skype is here is the run down. Skype is a program that allows users to call other users and converse with audio, text, or on the windows machine, video. Skype brings many cool things to the table and it was its video calling that really made me want to do this project.

Here's what I plan/am doing:
I've decided to create a application which binds itself to Skype and then allows anybody(except "banned" users) that is allowed to call your skype account to control your robot. I've got some screen shots attached and here's a run down of features i've implimented/hope to impliment:
Auto Answer Calls - Implemented - Allows you to go, your know, have a life while also allowing others to control your robot
Ban List - Not Yet Implemented - Allows you to ban users from control
SkypeMe Auto Change - Implemented - When the application starts it puts your Skype client into "SkypeMe" status so anybody can call you
Video/Audio source selection - Implemented - Allows you to pick which audio and video goes with each robot
Multiple Robot Control - Not Yet Implemented - I am hoping to allow multiple users control multiple robots, or one user to control a number or robots
XML Robot Configuration - Not Yet Implemented - I am hoping to allow robot administrators to save their robot configuration(Com Port, Video In, Audio In, etc) to an XML file for easy transfer and use
XML Protocol Configuration - I am hoping to allow robot administrators to actually modify their Protocol after the application is compiled. This way, if you want to add a new feature to your robot you just edit the Protocal configuration and the updated feature is then available.

Anyway, that's my application. What do you think about it. I'm hoping to finish it and then let the community have it. Any comments/suggestions/rants?

Regards,
DiablodeMorte

James Long · 2008-01-11 05:09

Diablo,

First let me say....it seems like a pretty cool idea.

I think it is original......and hasn't been done in this fashion (but I may be wrong).

I would like to know what type of robot are you targeting for control? (stationary robotic arm?....rover?....other?)

It is a different approach that I haven't seen yet....

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L

Partner/Designer
Lil Brother LLC (SMT Assembly Services)

DiablodeMorte · 2008-01-12 23:57

James Long -
My target for this project is actually a number of robots. I recently got a "boe bot" kit so my primary target for the application is the boebot. I have a few other robots which are mostly automated RC cars.

UPDATE
I need some help from some people from the community. I am working on the part of this project which deals with a modifiable protocol. As I said in the first post, I want people that use this program to be able to change the protocol configuration on command. I realize that everybody's robot is going to be different and I want to make this program as user friendly as possible. For this reason I have designed the following XML Protocol Configuration file:

<?xml version="1.0"?>
<protocol>
    <startDelimiter>255</startDelimiter>
    <seperatorDelimiter>$</seperatorDelimiter>
    <requireChecksum>1</requireChecksum>
    <checkSumCalc>LSB(FF - command)</checkSumCalc>
    <format>startDelimiter,command,seperatorDelimiter,checksum</format>
    <commands>
        <forward>
            <format>id,seperatorDelimiter,duration,seperatorDelimiter,speed</format>
            <id>1</id>
            <type>move</type>
            <adminOnly>n</adminOnly>
            <sendVars>
                <duration>
                    <required>y</required>
                    <default>0</default>
                    <max>100</max>
                </duration>
                <speed>
                    <required>y</required>
                    <default>0</default>
                    <max>100</max>
                </speed>
            </sendVars>
            <recVars>none</recVars>
            <use>/rcon forward duration speed</use> 
            <description>
                This function moves the robot forward for [noparse][[/noparse]duration] number of seconds at [noparse][[/noparse]speed] speed. 
This function does not return any information from the robot.Note: [noparse][[/noparse]speed] and [noparse][[/noparse]duration] are defaultly set at zero.
            </description>
        </forward>
        <getTemp>
            <format>id,seperatorDelimiter</format>
            <id>71</id>
            <type>sensor</type>
            <adminOnly>n</adminOnly>
            <sendVars>
                none
            </sendVars>
            <recVars>
                <temp>
                    <type>float</type>
                </temp>
            </recVars>
            <use>/rcon getTemp</use> 
            <description>
                This function gets the ambient tempreture of the robot. 
            </description>
        </getTemp>
    </commands>
</protocol>

My problem, and the reason I need help from the comminity, is that I have very limited experience with communication protocols with robots. I really need suggestions. Any comments are very welcome. If anybody doesn't understand a particular part of the above XML file please post back and I'll answer your question!

Regards,
Diablo

Post Edited (DiablodeMorte) : 1/13/2008 3:49:47 PM GMT

LoopyByteloose · 2008-01-13 11:01

Obviously, the audio channel is not much use unless you plan to transmit modem audio over the Skype channel. It would be wonderful to have the real time video either observe the robot's movements or be a roving camera on the robot. Since you can send text in chat mode at the same time that you are conversing in audio, that text mode is likely to be the best channel for a remote control dialogue with the robot. if that can be done, the audio channel would be free to monitor sound in conjunctions with the video.

In many ways, this seems a lot easier than a non-Skype solution. The main challange is having a command line processor to accept text from the remote user. I'm not sure that you have to bother with an HTML page, but I may be wrong.

It is an innovative idea and i'm sure Skype hasn't thought of it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 1/13/2008 11:06:12 AM GMT

DiablodeMorte · 2008-01-13 16:30

My plan for the audio channel was to allow the user to listen to the robot's surroundings. I hadn't even thought of using it as a modem but as you said, it would probably be better to control the robot using the text chat which is what I'm going to continue with. As for the XML file is posted. Let me explain it again. The posted XML is not a HTML page, its the configuration file for the protocol used to communicate with the robot via the PC. Because I want to make the protocol very flexible I wanted some input from the community. Let me break down my XML file

<startDelimiter>255</startDelimiter>
Every time I have ever done any networking I have had some kind of sync number/symbol in the front. Conceivably, if this was not needed one could just put "none" where 255 is. 255 could be any number/letter combination that one wanted
<seperatorDelimiter>$</seperatorDelimiter>
I have never actually used a seperator symbol before in serial networking, I have used it in TCP networking however, so I threw it in. Again, if one didn't want it they would just replace "$" with "none"
<requireChecksum>y</requireChecksum>
Again, I have never used a checksum in serial networking becasue I've never sent that much data and it was never a very critical application. I could see how a checksum would be useful. The "y" or "1" indicates that yes a checksum should be sent and a "n" or "0" would indicate that it would not be needed.
<checkSumCalc>LSB(FF - command)</checkSumCalc>
This line would indicate how the checksum should be calculated. In this case, the checksum would be the least significant byte of 0xFF - the command in hex. If the checksum was disabled in the previous line this line would simply be ignored
<format>startDelimiter,seperatorDelimiter,command,seperatorDelimiter,checksum</format>
This line would define the format of the serial command. Lets say the idea was to send the "forward" command for 50 seconds at 75 speed. The serial command would be:

0xFF 0x24 0x01 0x32 0x24 0x4B 0x24 0xC6

The check sum would be: (HEX) 1 + 24 + 32 + 24 + 4B = (decimal) 1 + 36 + 50 + 36 + 75 = (decimal) 198 = (HEX) C6

The idea with the "commands" would be to allow the addition on new commands quickly with a standardized format. Lets take the "foward" command. The forward command has the following subsets:

            <format> - Defines the format of the command, similar to the <format> above
            <id> - Defines the ID of the command, identifies the command to the robot
            <type> - The type of command, defines what the command does(in this case, move the robot)
            <adminOnly> - Defines in the command is adminOnly. If "y" the command is not accessible to non admins, and does not work if manually entered
            <sendVars> - The varaibles sent to the robot
                <duration> - One of the sent variables
                    <required> - If it is required("y") then the command will not be sent with out this variable
                    <default> - The default value if "required" is set to "n" 
                    <max> - The maximium value of the command
            <recVars> - the variables sent back from the robot to the PC
            <use> - The "use" of the command, displayed to the user if /rcon forward help is issued
            <description> - A description of the command, also displayed in /rcon forward help is issued

What I want from the community is: am I missing something?

FlyingFishFinger · 2008-01-13 18:23

Interesting. I was thinking of something along similar lines, without data feedback using only the audio channel. I've been using my Bot with my DTMF board and cell phone, I was thinking to use Skype to make an internet control by calling the cell phone from there. You just gave me the idea of using Skype video instead of setting up a seperate video host...my bot has a camera with video trasmitter, so I can use a digitizer to feed that to the comp[noparse]:)[/noparse]
Nice work

Raf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You've got to play the game.
You can't win.
You can't break even, except on a very cold day.
It doesn't get that cold.
~Laws of Thermodynamics~

DiablodeMorte · 2008-01-14 00:22

Just a quick update: Should I try to add DTMF support to the program? I've never ever used DTMF tones before but if other people actually use it then it might be useful!

FlyingFishFinger · 2008-01-14 04:15

Well I think it's not something for what you want to implement since you have other ways of data feedback, I was just thinking that that could be something I'd want to add for my personal use, just because I have a board that does something with it. Your methods of data transmission and control seem more efficient to me. I thought of using Skype for my Bot this past fall, but as you got there first...have at it. I'll build my own later.
Have fun [noparse]:)[/noparse]

Raf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You've got to play the game.
You can't win.
You can't break even, except on a very cold day.
It doesn't get that cold.
~Laws of Thermodynamics~

Robot Control Skype Plugin - About 40% Done

Comments