I want to get some ideas on how I might control a video camera through an IP address. I have an API to control pan and tilt from a local machine. The code is going to be in C/C++ on Windows. I am still designing if I want multiple cameras controlled from one application or have a one camera to one application. Would SOA be a useful architecture to structure my messaging?
I think you could be well served by something like REST for a task like this. Executing a command towards a REST server is really intuitive and simple, which sounds just like what you need. I'd probably make some kind of application that would be running inside a web-server, since this would handle most of the infrastructure, including authentication if needed. I'm sure both apache and IIS could do this for you quite easily. Even though your API is coded in C you could also consider using some higher-level scripting language as a client to the API (inside the web server).
SOA sounds a little overkill for a task like this.
I did something similar for aproject in my university. What we had was the cameras connected to a LAN and with message passing was very easy to communicate with them, is the same that communicate with any PC. We had the same application to communicate them. You can use SOA or any architecture you consider convinient, that depens on your application.
For our case was just an ad hoc architecture, it was not a complex thing.
Hessian is nice. It is basically REST, but has a binary protocol which is more efficient than XML and it also lets you make calls from other languages quite easily. So, you could develop the client GUI applciation in C# and the server in C. There are free libraries for a few different languages available.
http://hessian.caucho.com/
Related
On the DroneKit.io page, it mentions using DroneKit Python when creating Ground Control Stations for Windows. However, there appears to be no documentation for this.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
Thanks!
DroneKit-Python can be used either to create a python-based ground station or it can be run on a companion computer. There is no practical difference between the two except how you set up the connection to the vehicle from the computer running the script. The different ways of starting MAVProxy for the different connections are covered in the Getting Started documentation.
The reason that there is no "specific" documentation on using DK-Python for GCS is primarily "marketing". The far bigger market for ground station GCS software is in tablets/phones that will use DK-Android or a future iOS port. DK-Python has been positioned solely as for use in the air interface. Even though there is no "specific" documentation, in fact all the existing documentation is relevant.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
No. See above.
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
It doesn't mention low-latency processes, so the answer is "invalid question".
You're probably misreading the text "that require a low-latency link". The point here is that if you have dronekit-python running on a companion computer and connected by a fast link you can do real time handling of incoming sensor data. This allows computer vision control of the UAV. However if you run DK-Python on a ground control station you will have a much slower link. You can still control movement of the UAV but the latency will be much higher.
Hope that helps!
I have an application that began its life as a C#-based Windows GUI that used marshalling to talk to a C DLL.
I now need to separate the Windows client and DLL so that the client is installed on a remote PC and communicates with the C DLL over the internet.
A further complication is that I want to have multiple Windows clients connecting to the C DLL.
This whole world is new to me, so excuse me if the following are naive questions.
My questions:
0) What is the best method for having the client communicate with the DLL over the internet? TCP/IP Sockets?
1) I need to make modifications to my DLL to have it service multiple clients. But I need some piece of middleware that collects the queries from the different clients, feeds them to the DLL, and then sends the results back to the appropriate client. Is there any code (such as node.js) that would facilitate this?
Regarding: What is the best method for having the client communicate with the DLL over the internet?
Your suggestion of using TCP/IP could certainly (and likely will) be part of the solution, but there will be other components of the solution as well. The direction you choose will in part be made by answering whether you are using standard marshaling (COM), or custom? At the very least, your problem description suggests a scenario requiring interprocess communications.
There are many ways to implement. This diagram maps out a general approach, that based on your description might apply:
Components of Interprocess Communications
Read more here
Regarding: make modifications to my DLL to have it service multiple clients...
The dll is simply a file like any other. Several processes can read, and subsequently own content from, a file as long as the processes doing the reading adhere to common file access rules. I do not think you will have to modify your dll, at least for that reason. Just make sure the processes accessing the dll comply with safe file access protocols. (Safe file access).
I am currently building a chat server (meebo style).
The architecture is something like this.
Bitlbee over libpurple is on host B. Its a trivial server on data center.
User communicates with bitlbee via web server (just like meebo) on Host A. The backend of this web server maintains chat session. It just translates the user commands to proper bitlbee comamnd and sends back to host A.
The most important part here is that host A will be deployed in embedded Linux.
I have 2 questions.
To keep the chat session persistent I am thinking of using node.js. As its much more easier to create a real time application with persistent connection. But I doubt if its supported in such platform.
If I use C instead of node.js (I am not using any web server) I can talk to the irc server at host A by libirc. But how do I implement all the web server features in C (like session, url/cookie/post data parsing etc) ?
Also if you think my approach is wrong or there is a better approach please tell me how can I improve this architecture?
Note: This is NOT a high volume chat server.
If building V8/Node.js is prohibitive on the embedded platform, the next best thing would be to take the event loop and platform layer (libuv) and HTTP parser (http-parser) of Node, both written in C and use those as a starting point. These are the same libraries used to build Node.js so they are battle tested and will give you the performance characteristics you seek.
Ryan Dahl, author of Node.js, demonstrates exactly how to use libuv and http-parser to build an asynchronous web server in C.
Put a ZNC server between Bitlbee and the web-based IRC client. Bitlbee will think that the user has never logged out and ZNC can maintain a backlog of messages until the user connects again with the web client.
I would try to go with node.js if that is your choice, also what embedded system is it? As knowing that would help more. Also, another plus for node.js is that it does have session handling built it, but if you wanted to do it in C try and see if you can get a sqlite wrapper running on the embedded device to store the session information.
But, if possible stick to something with less work on embedded devices, feels bad to reinvent a lot of stuff or have to fiddle with compile issues for your device.
But I can't seem to find much about how the NX protocol actually works. I have heard it does something with sending X11 commands. But does this mean that the listening clients need to have an x server to run the actual commands and display them?
Basically, I am trying to figure out if it is possible to write an NX client for a web browser, because it sounds interesting to me. Thoughts?
Yes. NX is essentially compressed X-Window protocol.
It's not a spec, but here is a general introduction to how it works: http://www.nomachine.com/documents/NX-XProtocolCompression.php
The client doesn't need to be an X-server, but it will probably need to be able to handle at least some subset of the X protocol.
If you are going to create an web based NX client, make sure you look at noVNC which is a web based VNC/RFB client. Better yet, fork noVNC and add NX support. That way you don't have to waste time on input, events positioning, networking, etc.
Disclaimer: I am the creator of noVNC. Implementing other remote desktop protocols (NX, RDP, Spice) is on my long term todo list (part of the reason for the name). If you're serious, contact me via github and I can give you some direction/thoughts and put you in touch with somebody else who has also expressed interest.
I am designing an application that requires me to access devices connected to the machine. We will have control of the machine, meaning control of the software and OS installed.
I know in the past one might suggest active-x controls, I was wondering is there a better solution? I have looked into Silverlight as an alternative, but not found much information supporting that design approach
Well, in theory, there's tcp support in Silverlight and so you could use that to talk to a local piece of software. In reality, tcp won't connect to the local machine unless you're in debug mode. So, that's a problem.
What people have been doing is creating a local WCF service and communicating with that. If you take this approach, don't forget to host up a cross-domain file as well.
I'd just add that if you can control what's on the client machine, WPF may be a much more straightforward answer :)
If you are speaking of the client's machine, Silverlight will not be of much help since it is sandboxed. In fact browsers and plugins are so locked down, that I think you should change your approach (maybe deploy your own client app, instead of using a browser/web app?)