I think that quantum teleportation can be realized by the Microsoft Quantum Development Kit, but by placing one piece of data (name A) on a PC not connected to the Internet and acting on one side (name B) Is it possible to react experimentally?
In the sample code, I do not feel realized just by comparing two variables in one code in one PC.
At the moment, Microsoft's Quantum Development Kit is focused on making it easier to write programs that act on stationary qubits such as topological qubits built using Majorana fermions. In that context, teleportation is a useful procedure for moving information around inside a single quantum device.
That said, you are quite right in that teleportation can also be used to transfer quantum states between distinct quantum devices — qubits such as polarization modes of photons that are used in such procedures are often called "flying qubits" to distinguish from stationary qubits. If you're interested in quantum networking protocols such as quantum key distribution that focus on what you can do by sending flying qubits, I'd recommend looking at the SimulaQron project. Their implementation of teleportation can be run on two distinct classical computers that share a classical network connection to simulate sending flying qubits.
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've done many projects that include a PC & an arduino / PLC / some kind of other microcontroller / processor, and in every project we had a different protocol used for communication between the PC application and the embedded one. Usually the hardware / controller developer invents a simple protocol which always changes throughout the project, and goes into the form of
Barker | Size | Data | Checksum
This time I'm implementing both sides, so I figured - This has been done a million times before. There must be a base protocol for these things with implementations in C, C#, Java, and such.
What I'm looking for is a lightweight layer that transfers stream based serial communication into a message based one.
I've been looking around for one for a while, but I couldn't find anything on my own.
Do you happen to know one?
I had exactly the same requirements for a recent project and I found nothing simple enough for low-end 8-bit microcontrollers. So I designed MIN (Microcontroller Interconnect Network) to do the job (inspired by CAN and LIN).
The code is on github here: https://github.com/min-protocol/min (check out the wiki there).
I defined a layer 0 (the UART settings) and layer 1 (the frame layer, with checksums, etc.) plus a C API.
I'm also working on a higher layer that formally defines how sensor data (temperature, pressure, voltage, etc.) are packed, with a JSON representation and a tool to autogenerate the embedded code to pack/unpack them from frames. The end goal is to create a Wireshark dissector that can be clipped on to the serial line and when fed with the JSON will display the signals in human-readable form.
I wrote a blog post showing a Hello World app running on an Arduino board (with an FTDI UART-USB breakout board carrying the data up to my host PC):
https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/
This serial problem occurs so often that it would be nice if we as a community just nailed it rather than keep re-coding it for every project.
Check Open Source HDLC
I recently came across MIN - never used this one though
Also check this
Simple serial point-to-point communication protocol
Using X/Y/Z MODEM protocol must be a good choice to solve your problem. It's easy to implement and ready-to-use. I use X-MODEM on an ISP tool communicates with our cortex-m0 powered MCU, and it works pretty well.
I'm trying to learn a bit about FPGA cards and I'm very new to the subject. I'm more of a software developper and have had no real experience programming FPGA devices.
I am currently building a project on a linux OS in the C language. I would like to know how it may be possible to implement such code on an FPGA device. For that, I have a few questions.
Firstly, do I have to translate my code to VHDL or can I use C? Also, how would one come about to installing an OS on an FPGA card, and are there devices that already have an OS installed in them?
Sorry for the newbie type questions, and any help would be appreciated!
FPGAs are great at running simple, fixed data flows through parallel processing, while CPUs are optimized for complex and/or dynamic data flows.
The C language is not designed for describing highly parallel systems, as it follows a clearly sequential pattern ("assign a to b, then add c to d"); while compilers introduce some parallelization as an optimization, the focus is on generating code that behaves as if the instructions were sequentialized.
In an FPGA, on the other hand, you want to break up sequences as far as possible and create parallel circuitry and pipelines, so normally the system is described in the form of interconnected blocks, where each is kept as simple as possible.
For example, where you have (a+b)*(c+d), a CPU based design would probably have a single adder, feed it with a and b first, then with c and d, and finally pass both results to the multiplier.
In an FPGA design, that is rather costly, as you have to create a state machine that keeps track of which of the three computation stages we are at and where the results are kept, so it may be easier to have two dedicated adders hardwired to a and b, and c and d, respectively, and to have their outputs connected to a multiplier block.
At this point, you basically have created a dedicated machine that can compute this single term and nothing else, but its speed is limited by the speed of the transistors making up the logic gates only, and compared to the state machine you get a speed increase of at least a factor of three (because we only have a single state/instruction now), probably more because we can also discard the logic for storing intermediate results.
In order to decide when to create a state machine/processor, and when to hardcode computations, the compiler would have to know more about the program flow and timing requirements than can be expressed in C/C++, so these languages are not a good choice.
The OS as such also looks vastly different. There are no resources to arbitrate dynamically, so this part is omitted, and all that is left are device drivers. As everything is parallel, these take the form of external modules that are simply linked into your design, and interfaced directly.
If you are just starting out, I'd suggest you get a development kit with a few LEDs, and start with the basic functionality:
Make the LED blink
Use a PLL block from the system library to derive a secondary clock, and make the LED blink with a different frequency
Add a simple bus interface, e.g. SPI, and communicate with a simple external device, e.g. a WS2811 based LED strip
After you have a basic grasp of how the system works, try to get a working simulation environment (the equivalent of a Debug build), and begin including more complex peripherals.
It sounds like you could use a tutorial for beginners. I would recommend starting here and reading through an introduction to digital design. Some of your basic questions should be answered by reading through these tutorials. This will put you in a better place to ask more specific questions in the future.
In previous versions of Arduino, the limiting 8-bit microcontroller board, it seems that implementing HTTPS (not merely HTTP) was almost impossible. But the newer version of Arduino Due provides 32-bit ARM core - see spec here.
I tried to check several network libraries (libcurl, openssl, yaSSL), but I didn't find anyone that was already ported to work with Arduino Due.
OpenSSL is probably too heavy to be able to run on this processor, but I believe that yaSSL as an embedded library should be possible to do.
Do you have any information of a library that I can use to trigger HTTPS requests on Arduino Due?
Unfortunately this is too long for a comment.
► No out of the box solution
From what I have gathered, there is no straightforward solution for a webserver running on the Atmel SAM3X8E ARM Cortex-M3 CPU that outputs HTTPS out of the box.
Texas Intstruments provides better options at the moment using their boards equipped with a Stellaris Microcontroller ARM Cortex-M3 CPU.
► Alternative
There are several options available that render cryptographic functions, based upon which one could lay out and implement a simple secure communication protocol that communicates with an intermediary device, which in turn facilitates Rapid Application Development and SSL.
This intermediary device, for instance an off-the-shelf 70$ Android smartphone that keeps your project mobile and connected, runs a service on a specified port which in turn communicates with Amazon SQS. Already available. This may sound ugly or tough, but is much easier than doing the programmatic groundwork for a webserver with full TLS 3 support on the Arduino. Given the proper motivation the latter may be easy, but not if one just wants a fast pragmatic solution to one's own project.
► Cryptographic libraries
crypto-arduino-library http://code.google.com/p/crypto-arduino-library/ (not maintained since 2010)
matrixssl
mbed TLS (formerly PolarSSL)
wolfSSL (formerly CyaSSL)
► Discussions
Following is a list of discussions to get you started:
HTTPS alternative on Arduino
SSL from a Microcontroller
Lightweight Packet Encryption
Many of these libraries would still need to be adapted, but community experts can help you with that fairly quickly.
Good luck! If you are at liberty to upload your final project to github then you just gained a thanks and a follower.
IMHO Arduino (including the DUE) is the wrong tool for heavy and/or encrypted web based communication. I would strongly suggest to look for more appropriate hardware in the same size and price range. As soon you get into https you are close enough to also want a lot of the other stuff that real operating systems provide. With other words I suggest to go for something like the Raspi. Similar size and prize but way more powerful, especially it can run Linux. --> HTTPS becomes simple.
The big problem with https support on an arduino is the danger of overloading your processor which could make the project unviable.
Even embedded platform targetted solutions like PolarSSL can eat up too much memory and use too much processing power. Remember that even on the most streamlined implementations, SSL support is going to have to be generalized for wide adoption and will include components that you won't find necessary. There's also the question of which Certificate Authorities you will trust and how you will communicate with them for things like certificate revocation.
I would look instead towards a solution that isn't as broken on the surface for your needs. Something like CurveProtect, which is an implementation of CurveCP.
Of course, your decision will largely be based on what you want to do and how much time you want to spend figuring the problem out. PolarSSL has a footprint that can be as small as 30K (more typically close to 100K).
I need to implement a 2-player pacman in C. The game will accept users apart from the two playing, however in view-only mode. Then they are admitted to the game in FIFO fashion.
I'm not so sure about which approach to take. I'll be definitely using the ncurses library to deal with the graphical aspect of the game. However I'm not sure about which IPC structure to use. Excluding the socket API, what do you think would be best and most straightforward way to deal with this problem?
Excluding the socket API, including only the low level APIs, I would use named pipes to get the job done quickest.
I think it's more complicated to think of this as an only two player game.
Easier to think in terms of a generalized client-server arrangement, with any number of players.
Have a server holding the game state, with clients connecting. That arrangement is easily understood and worked with.
Having only two clients and each maintaining the game state while receiving updates from the other is awkward.
Either way, use sockets. That way you get proper location independence.