views:

117

answers:

5

I want to control multiple robots using my laptop. Robots do not have intelligence, they are sending sensor values to PC which computes the sensors values and sends back result to robots.(Centralized control of robots using PC ).

Robots are communicating with PC through serial communication using Zigbee mudule.

Problem: How to make & send a structure (from robot) like {sen1, sen2,sen3..,robot id} where sen1, sen2..are sensors values and robot id is to recognize particular robot. After editing..... The code I was using for sending sensors was like.

 void TxData(unsigned char tx_data)

{   SBUF = tx_data; //Transmit data that is passed to this function
     while(TI == 0); //wait while data is being transmitted
}

and then sending sensor values one by one

 TxData(left_whiteline_sensor);
 TI=0; // resetting transmit interrupt after each character
 TxData(middle_whiteline_sensor);
 TI=0;
 TxData(right_whiteline_sensor);
 TI=0;
 TxData(front_sharp_sensor);
 TI=0;

At PC end reading these values in buffer

read(fd, buf1, sizeof(buf1));
.....
options.c_cc[VMIN]=4; // wait till not getting 4 values 

This was working fine when there was only one robot, now as we have multiple robots and each robot is sending data using above function, I am getting mixed sensor values of all robots of at PC end. One solution is to make a structure which I mentioned above and send it to PC. This is what I want to ask "How to make and send such a structure" Sorry for not framing question correctly before.

Thanks...

A: 

I don't know what API you are using from the PC to communicate with the endpoints (robots), but I'm guessing that when you send data you specify either the short address, the long address (MAC), or some socket/file ID which you opened using one of the long or short addresses. Also, I'm guessing that the robot id is the same as the short address -- if not you will need to create some code to map back and forth between the robot ID and the short address. I'm also guessing that you are either using something like the select system call to wait for data from any of your robots or trying to read from each one.

If this is the case then you should be able to create a state machine for each robot and whenever you get data from that robot you feed that robot's state machine which processes it and generate a reply to that robot (or even sends data to the other robots' state machines). The state machine will be almost like your single robot program, except that it will rely on an event loop getting data from the robots for it. You may also want the event loop to be able to supply timer alarms for the state machines. This is similar to the way you would write a http server that could handle multiple clients at one time.

If I was totally wrong about your API and you have those zigbee radios that just act as a serial port without wires then you are in a mess, because I think that you will have to reconfigure them in order to use more than one endpoint at a time -- and will have to change the API you use to communicate with the robots.

nategoose
A: 

This kinda defeats the purpose, since RS-232 is not a bus line, meaning you have no address space. you'd need to connect your RS-232 line to a controller, that runs the bus for your motors or whatever. and basically encapsulate the data from the controller to your software running on the computer.

polemon
A: 

It sounds like you need to create a protocol for communicating between the 'bots and the PC. It could look something like this:

Byte   Value  Description
 1     0xAA   First sync byte
 2     0x55   Second sync byte
 3     seq    Message sequence number, increments for each new message transmitted
 4     1      Message type (1 = Wheel encoder report)
 5     5      Number of data bytes to follow
 6     ID     Bot ID
 7     FL     Front left wheel encoder
 8     FR     Front right wheel encoder
 9     RL     Rear left wheel encoder
 10    RR     Rear right wheel encoder
 11    CS     Checksum of bytes 1 - 10

Now if the messages are not sent in discrete packets (i.e. UDP), but asynchronously over a serial port, then the message bytes from different bots could become intermingled. The above protocol will at least verify the integrity of a received message, but the probability of receiving a valid message will decrease as the number of bots simultaneously transmitting to the PC increases.

A method for solving the asynchronous problem involves embedding the bot ID in each byte transmitted. If there are no more than 16 bots, then their ID could be placed in the upper nibble of the transmit byte and 4-bits of data in the lower nibble. It would then require two transmit bytes to send one data byte: 0x1F + 0x13 = 0x3F from bot #1. This would double the size of your messages and require code on the receiving side to parcel the incoming data into separate receive queues for each bot.

jholl
+1  A: 

Look at RS-485 if possible. It is still serial from the PC point of view and it supports multidrop. I've developed a robot where most of processing was done in the PC side and all other boards were connected in a daisy chain to one RS-485 bus.

Padu Merloti
A: 

try open-ZB

plan9assembler