1. Home
  2. General Robotics Forum
  3. Web controlled robot

Web controlled robot

Hi all.

Just after a bit of a pointer.

I have a robot with serial comms. I have an SBC running linux redhat

6.2 and appache web server.

The robot uses a few pics for control. hooked up to one main pic. This is supposed to act as a low level controller.

I wish to use the sbc to "think" for the robot and also display live data on the web server and take commands from the web page to move the robot. High level mapping/route planning etc I would like to do in gnu C.

My problem is how can I get live data from the robot to the web page and commands back to the robot all trough high level control software running on the SBC.

I would like to use cgi scripts or C.

Should I be looking at writing an appache module or something, or is there a simpler way. I have thought about exchanging data though a database or enviroment variables but this seems a bit messy.

Everything is configuarble at the moment. Im writing the robot pic-micro software in C. The SBC linux side is currentley in C but still embrionic.

Any ideas, pointers, web links etc much appriciated.

Thanks Rob

rob at robsbots dot co dot uk

Reply to
robs bots
Loading thread data ...

One way you can command your robot is via CGI invoking a C program that sends commands over the serial port to the PIC.

If you want live data to be displayed on the web page, use AJAX. I haven't used it personally, but a buddy of mine did, and the results are impressive.

BRW

Reply to
BRW

I mocked up a simple robot control and status display in ajax earlier this year. (For a robot that I subsequently abandoned for unrelated reasons.) Ajax is definitely what you want to go with for real-time systems like robots. I would recommend *against* touching the serial port directly from a CGI script, however. There are a few reasons for this: (1) you can get several web requests at a time, and contention will lead to unpredictable results (2) if you're reading data from the pic, your CGI will have to open the port and wait for whatever data you want to display to come it. The way I did it was to have a simple perl daemon (you could do it in c with a few more lines of code) open all the serial ports (the robot had a few of them) and record the incoming data. It would also open a local tcp socket. CGI scripts would connect to that and query for particular items of data (which the daemon cached so were available instantly) and issue commands (which the daemon could apply arbitrary command policies to.) You could also write a controller program that uses the same API as the CGI scripts. That way changing the high-level control does not require restarting the low-level input/output systems.

-chris.

Reply to
e c kern

A common approach to this problem is to write a daemon, a back-ground program, that talks to the serial port and device, and offers a protocol to UI programs such as a web server.

This was the approach we took in our book "Linux Appliance Design". We had five types of UIs : web/AJAX, command line, framebuffer and LIRC, SNMP, and a hardware based front panel. We used the RTA library on our daemon (a simple alarm system) to give the common protocol used by all of the UIs.

hope this helps Bob Smith

Reply to
Bob Smith

Thanks Guys. This looks like it could be the answer. Had a quick look on wiki and it sounds right, so on with a tutorial. If I get anything going I'll post a ulr to play with :)

If not I might be back for more advice. ;)

Reply to
robs bots

Thanks all.

I have started playing with deamons in C. I've got my program to fork off to make it a deamon. Im gonna use a fifo pipe (probably on a ram disk so I don't over use the flash disk) and then get the data via Ajax onto the web page.

Ajaxpipedeamonrobot

The deamon will handle all the serious bot code such as mapping / path planning etc.

I havn't got the fifo pipe working yet. Thats the next step. Then on to ajax to see if I can get some live data up.

Cheers for the pointers

What this space..........

:-)

Rob

Reply to
robs bots

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.