Automatic changing conditional case structure for switching nodes

[thedawg1993]

I'm working on ground drone development project with NI MyRios and XBee communication protocol through antennas. The goal is to have one central command computer that can communicate with the drones, and change certain settings on the robot.

I would like to have the computer send a serial message to one of the robots, allow the robot to change any of the current settings (if needed to), and respond with a status update for the robot. The computer would then communicate with the next robot, and cycle through all of the robots in continuously. Each robot has a different identifying number (1,2,3,...) in the serial message. I would like to use for loop to change the robot number automatically and have a certain condition met before changing the robots.

I'm not quite sure how to set this up in LabVIEW. Any suggestions on how to do this?

[JÞB]

Well, the first thing to consider is how to build the LabVIEW based driver for a "Drone/Robot"  This would be the area where you decide what messages need to be sent and received.  The details of this are hidden in that library. things like "Open A Session to Device x" Discover all devices, Close Session to device, Send message (Broadcast) and Send Message (Dev#) read from device.  You know the generic I/O operations that will be done.  OUT of the OSI model Layers 1,2 and 3 are handled by XBee, layers 4 and 5 by VISA you only need to translate human understandable IO to message strings. to build your "Drone/Robot" API (Instrument driver)

Now,y'got's ya'self (You Have) one antenna at the "Control side" many of the rest of the structure depends on how that antenna is used,  Is it full duplex, half duplex multiplexed in Code, Time, Frequency....?  XBEE can do most or all of that.  That is the question that drives decisions on "Do I spawn 1 actor per Discovered Device or one Actor to service devices?"  And that all depends on where the "Intelligences" are.  Do the drones play "Simon Says?" or do they respond to commands that are more abstract?  

A Simon Says robot might get a command "Go Down 20 Feet" and just descend 20 feet reporting that its current altitude is 20 feet lower than when it received the command.  A more advanced robot would understand the ground is only 5 feet below it and report a "command rejected" error.

I hope that serves to help you understand that you have not provided enough information to design the software architecture . 

[matthewRC]

It sounds like a state machine might be a good fit. The program runs in a state until conditions are met to change to a different state. Each state would be a different drone. 

State machine tutorial

Matthew C. 

NI | AE