I am looking to make a remote control car with a camera which can be controlled via an Android Phone. This requires a lot of things, but the only thing i am confused about is how to communicate the camera's image with the phone. I can handle the code and stuff and i know networking well, and i've done server-client many many times, but what i really need is to know how i can hook up a camera to some sort of WiFi enabled motherboard on the RC Car. The RC Car should be able to communicate over WiFi and i also want a motherboard which would let the WiFi data coming in from the client (Android phone) control the motor speeds and stuff. Where do i start? I'm really confused on how data being sent over a socket to my RC Car will control the motors, and also how camera data from the car will be sent to the phone.
Basically, I need a way to have control over motors and also have a way for the car to send me video. How do i do this?
You have to stream the cameras input over the network. In order to achieve this you could use the Gstremer in both car-(streaming server) android phone ( client ). With a gstremer you will set the camera as your input stream and rtsp sink as a renderer so you client ( iphone app ) will be able to connect to the live streaming server on your car.
Related
I am making a game of Bingo. For that I will be connecting two mobiles via wifi- hotspot and the grid should be shared to both clients, that is both mobiles should see the grid. How can i pass the grid two both clients? Also, how to pass numbers in between client and server? Via object or other thing and how? Also how to exactly implement client server application making 2 java files n android? PS: we are not implementing a chat application.
Bingo XML file: https://github.com/TanishaShrotriya/SDL/blob/master/activity_main_bingo.xml
Java File:https://github.com/TanishaShrotriya/SDL/blob/master/MainActivity_bingo.java
You have a few options. First you need to determine which architecture works for you.
Client/Server (AWS Instance with APIs, and Firebase with PUSH)
---This will enable the devices to get current came status on open, and push changes to their board on confirming their space was called/filled.
---This will enable other devices in that "room" a name given to a virtual shared space for a game. To receive PUSH notification of changed data to display.
Next you need to decide if the server will maintain the full state of each user or just the current called values for comparisons.
If you decide that you do not want to write APIs and setup a Server for PUSH, you can do an ad-hoc wi-fi or even a BLE based communication among everyone in the area. However, this will require significantly more understanding of how to pass bytes, handle network issues, latencies, and communicating from device to device.
If you choose to do the ad-hoc wifi as you mentioned you would have to maintain a ton of connections like a mesh network. A better option would be to have all devices join the same wifi network so that they have access to each other, but aren't necessarily keeping track of mesh networking.
However, even if you are on the same wifi knowing who to send the information to can be difficult without a server to retain routes and IPs of current players. So you may have to create a host so that it can listen for enrolled players. The host device would need to retain routes to all other devices so that it can send the info to each IP address when a change occurs.
I still highly recommend going the client/server route of APIs and PUSH it will be far more reliable.
Now as far as how to pass the data, you could of course screenshot via code and send images, but that is wasteful. I would recommend having a matrix that keeps track of the values covered and simply send a JSON snippet of the card_id, the player_id, and the json of covered blocks to the server that can then push changes back to all players in the "virtual room". This allows them to see how their fellow competitors are doing.
So I would have to ask for more details about what your goal is to help any further, but that is my recommendation, because ad-hoc wifi or bluetooth is doable, but on a mesh scale size you will have a giant headache on your hands. The host scenario device with all on same wifi would be my second direction if you are really anti-server and APIs, which the only reason I could see you avoiding that is if you wanted to play off wifi that doesn't have internet or if you don't want to pay the $30/month for traffic while it is small.
Let me know if that helps or if you want to provide additional clarity.
I'm working on a project that can help optimize multicast. More precisely an implementation of Network Coding.
I have a great deal of it done in simulators, but now that I want to implement it on actual mobile phones, I'm facing this problem: How can I send data between them phones without the need for access points between them?
Can I open sockets programmatically and listen to them? Or is there something like an AdHoc network (those are no longer supported in android) that I can use?
EDIT: If needed I can rely on a server/access point for DHCP and such (for the phones to know of each other) . But the data needs to flow between the phones independently of the access point.
An access point is just a 1st-level ISO/OSI device that permits to one or more WiFi compliant devices to communicate wirelessly. Unless you can use Bluetooth or IR as a fallback, there's no way you could make it without an AP.
Have one of your phones act as a "mobile hotspot" (a wifi access point) for the other phones. Share the name of the access point and passphrase with the other phones and they will all be connected on the same network (and the internet through the "hotspot" phone's cellular data connection.
In this way, you have all the normal networking capabilities and security available to you without requiring an additional/external access point.
However, this will not result in direct connectivity between the many phones that are not the access point; all (non-multicast) network communication will bounce through the phone that is acting as an access point for your network.
I am working on an app that will act as a dashboard for an electronic card installed in cars and trucks.
I need the application to be able to receive data from this card, so I can display it in various ways on the app.
We chose Wifi for the communication method. To access the card, my app is able to connect to a Wifi network created by it.
I would like to receive JSON sent by the card every second.
I need help on where to start to make the two devices communicate, and what are the good practices on implementing this kind of communication.
The app basically act as a client, and the card as a server.
I found something about sockets, but it seemed to use two Android devices, a server and a client, so I'm kinda stuck here.
I use Android Studio 2.1.2 with the Android APIs ranging from 19 to latest.
One option is to broadcast with UDP the data within the local network. The moment the android device connects to the wifi network it will be in its local network. So the data can be received at the android end with a multicast receiver(check out http://jgroups.org/ ).
Refer example
It may also use the p2p sharing with TCP and bind the device with static IPs for communication. Create a simple socket receiver at the android end and a service at the device end. Depends on the way you choose it.
The scenario:
My friends and I are developing a product with a bluetooth reciever that connects to a speaker system. Currently we can pair with this unit and stream music over a bluetooth connection. I'd like to develop an app that I can use to control different settings on our unit while the music is streaming. My application needs to be able to do this no matter which app is streaming the music over bluetooth (native media player, spotify, pandora etc.). I'm thinking this potentially a permissions issue as opposed to a bandwidth issue...
I need to know:
Is it possible to send control data and an audio stream concurrently to the same bluetooth reciever? If so, could someone please point toward a good strategy that will help me accomplish this (eg what protocol to use for the control data)? If it is not possible, can someone recommend a better way to control the target device?
I wasn't able to find what I was looking for in the Android Developer docs.
Based on my knowledge from working with bluetooth, the best method would be to send the control packets in the same packet stream as the audio packets, appending a unique ID to allow the speaker the ability to recognize and act on the control packets.
Ideally, you would want a Connection Stream on the speaker built just for control. so that way your app just connects to that and sends the connection data, which the speaker then interprets.
Pseudo code for the speaker would look something like
connectionURL = "btspp://localhost: " + uuid + ";name=control";
bluetoothConnection.open(url);
while (true) {
// waits on this line until something tries to connect to it.
bluetoothConnection.acceptAndOpen();
/* Process control information */
}
As for pausing music from a third party app, the easiest way would be to have the App Request Audio Focus to pause and release it to resume. Alternatively, you could have a control packet sent that would cancel the bluetooth stream of audio, but that could become quite complicated to resume.
I would like to establish a connection between a mobile device and computer so they can interact with each other. I should be able to send and receive data at both the ends, just like a chat client. How do I go about it? I just want to know the steps involved. I was thinking about sending the data from the device to a database server and then accessing it through the PC, and doing the same on the mobile device, too. Is this a good idea? What alternatives are there?
Since you're using android, this is pretty easy. One easy option is to code a client and server application for your android device and pc. Or, you could just send data on the UDP connectionless protocol.
I'm assuming you know how to build apps for an android phone. There is no need of an intermediate node (a database server or the like), if the goal here is as small as just sending data back and forth.
Here's a good example of a UDP server/client implementation.
And here's a good one for TCP server/client.
Hope that helps.