2017년 4월 20일 목요일

[Test] Arduino USB Serial Extension


I created this extension for all Arduino lovers to be used in your projects. This extension has been created using Physicaloid library.

Some highlights of this extension:

⦁ USB-Serial communication
⦁ upload a firmware to an Arduino
⦁ support on Android 3.1 or higher (need USB Host API feature)
⦁ does not require ROOT
⦁ support USB-Serial protocols : CDC-ACM, FTDI, Silicon Labs CP210x
⦁ support uploading firmware protocols : STK500, STK500V2

Currently, this is just for testing which includes some basic things such as:

⦁ Open/Close connection
⦁ Read/Write

Other features that need to be included are:

⦁ Upload .hex files to Arduino
⦁ Support for upload files from assets folder

Extension has been attached here.


--
Please test and provide feedback on how well this works.

-- 
Hello Pavitra I downloaded it thanks for the contribution, I will try to see that such, although I already tell you

-- 
Sir the Extension is very useful. I have downloaded and used it but it is not working. Maybe it is of my fault, anyway it would be better if provide a sample program or the image of the block editor of a sample app. Good Work!

-- 
I haven't test it yet with an Arduino. So, I cannot give any word on this. However, I am looking for testers. Would you help me in testing? (It shouldn't take longer that 2 to 3 days)
--
I have one doubt, That most of the serial communication asks to set the the baud rate and in this I didn't found anything like that

-- 
I set the baud rate to be 9600 by default. I will make it able to set baud rates in the next release.

--
I'm trying but does not working, there is an advertisement (com/physicaloid/lib/usb/driver/uart/UartFtdi).

Whit the same connections I've tried https://play.google.com/store/apps/details?id=bp.usbbridge.appinvDemo&hl=it  and It is Ok.

Thanks for your idea.

-- 

Translate the description in English using Google Translate Translate
Attention !! For more information on how to do this, please visit the Github: https://github.com/S2I71/usb_otg_bridge_app_inventor/

Demo version: Try before buying the full version but a screen is displayed with a tempo of 10 seconds between each communication. Fixed speed at 115200 Baud.

Full version:
Possibility of changing the transmission speed: BAUD300,600, ... 57600,115200 ...
More screen with tempo; Completely transparent.
Https://play.google.com/store/apps/details?id=bp.usbbridge.appinv

Create in 10 minutes your application on your android tablet which communicates in USB with your Arduino card.
Download the following example: https://github.com/S2I71/usb_otg_bridge_app_inventor/

Students, teachers, communication enthusiasts discover the first application to control UART FTDI devices with a USB connector (Arduino uno, Mega, Yun, FTDI Xbee ...) directly from the APP INVENTOR 2 development tool (No shield host usb or bluetooth, just an OTG USB cable)

USB Bridge for App Inventor 2 allows an OTG USB cable to interface seamlessly between a USB device and the APP INVENTOR 2 development tool.

You will be able to develop your own new applications allowing to use the power of app inventor 2 (graphic, sensors, database ...) and the powers of your peripherals (LED RGB, Servo, AX12A, DC motor ... ) With USB UART at 115200 baud.

Use and recycle your old phones using its internal functions instead of using multiple arduino shield: touch screen, display, mp3 player, SD card reader, sending SMS, GPD, GSM, QR Codes, NFC, bluetooth, wifi , Various sensors ...., for your microcontroller based applications. (Arduino, Teensy, XBee ...)

If your device is not recognized, send me the Vendor ID and Product ID references as the following example for the arduino uno: Vendor ID: 0x2341, Product ID: 0x0001


USB Host mode must be supported + Android 3.1 mini

Example: Controlling an arduino uno card with a USB cable otg and APP INVENTOR 2
(Test OK 115200 baud with an arduino mega ADK card)
In the demo version you just have to change in the app inventor activity:

Change: bp.usbbridge.appinv to bp.usbbridge.appinvDemo
And: bp.usb.bridge.appinventor in bp.usb.bridge.appinventorDemo

Send receive data from Arduino Serial.println (), Serial.print (), Serial.read () card to 115200 baud or other (full version).

Version of the Arduino program under Ardublock.


Https://github.com/S2I71/usb_otg_bridge_app_inventor/

--


--













--
I've seen with DroidScript is possible by USB OTG, receive or write data from/on arduino, I'd like to use app inventor, can you see how DroidScript works and make the same with app inventor?

-- 
I will soon open source it so that many people can contribute to it to make it happen

--

Great, will check into it as soon as i get my otg cable

--


search for firebase game


Hi All. I'd like your opinion on which would be best to use in this scenario: Firebase or a Fusion Table. I have a two-player game, and when Player1 ...
It is my understanding that I can use firebase to make this playable across 2 devices (each player using their own device) is this correct? If so...I will be ...
Here's a board search for firebase game: https://groups.google.com/forum/#! searchin/mitappinventortest/firebase$20game%7Csort:relevance.
My game is not complex, it would connect 2 players and they would only share de score. I can use a firebase bucket for that. What i cant understand ...
Another option would be Firebase. You can exchange data via the cloud, using the experimental AI2 FireBase component. Some people managed to ...
Do you want to write a game that you can play with more people? The answer is yes. You need to have ... player can access it. This can be a TinyWebDB, a Fusion table, your own website, or, later this year, Firebase. Cheers, Ghica.
We have been tasked to build a Multiplayer Top Trumps Game using app inventor and Firebase. Does anyone know if this would be posssible with ...
... CardSave and load a CSV TableFireBaseFirebase WhatsAppInventorMIT chat project - MontesUploading Files to FireBase - Thunkable forumBrief ... Drive ( Taifun)Google Earth from KML using Activity StarterGoogle Game Services Leaderboard/TaifunGoogle Maps with Markers (Discussion)MQTT ...


MultiPlayer Rock Paper Scissors on FireBaseDB


2/26/2016
Abe Getzler

The objective of this exercise is to test FireBase DB’s suitability as an AI2 vehicle to run a multiplayer game like Rock Paper Scissors (Rochambeau).

GameTypes
RPS
name: “Rock Paper Scissors”
blurb
moves : [Rock, Paper, Scissors]
winning moves
Rock
Scissors : crushes
Paper
Rock : covers
Scissors
Paper : cuts
RPSSL
blurb
moves : [Rock, Paper, Scissors, Spock, Lizard]]
winning moves
Rock
Scissors : crushes
Lizard: crushes
Paper
Rock : covers
Spock: disproves
Scissors
Paper : cuts
Lizard : decapitates
Spock
Scissors : smashes
Rock : vaporizes
Lizard
Paper : eats
Spock : poisons

Game Types could be kept on the server, to allow for new game types being introduced from the server side.  (Not implemented yet.)


Design methodology

To avoid conflicts from simultaneous updates; we will try to follow these rules on the server side


  • never store summaries (counts, maxima, sums, analyses)
  • never update anything in place unless you own it and no one else reads it.
  • never keep lists, only subtags.
  • only insert.


Also, because a FirebaseDB query with a unique tag will return as a value the JSON of everything under that tag (but not the tag),  we will include a duplicate of the unique parent ID under the subtag ID, to make it accessible through the lookup-in-pairs block.

Server contents:



PlayerNames

Player name (unique, scrub blanks and quotes)
ID : playerID  
last login datetime
current match ID
challenge question  (not yet implemented)
answer (not yet implemented)
newsfeed
matchID1 : last move YYYYMMDDHHmmss
matchID2 : last move YYYYMMDDHHmmss
matches
match ID YYYYMMDDHHmmss-Initiator
matchID : matchID  (duplicated for convenience in JSON extract handling)
game type
target rounds : 3
target players : 2
players
player 1 ID : true
player 2 ID : true
...
current round : 3
last move YYYYMMDDHHmmss (for cleanup)
rounds
1
player 1 ID: move
player 2 ID: move
2
player 1 ID: move
player 2 ID: move


          • ...

Players get to choose their own name, mirrored in TinyDB.  Names must be registered on the FireBaseDB server to insure uniqueness.  The challenge question and answer are filled in at registration time to allow the player to reclaim his Player Name into TinyDB on a new device without being rejected as a duplicate on the server side.


Players get to play multiple matches simultaneously, since opponents might be scattered world-wide.  


(TODO:  The newsfeed system might be unnecessary, if players monitor their current game directly in its host player subtree.)


To allow each player to have to monitor only one FirebaseDB key,  the newsfeed subkey of each player ID has subkeys for each match that might require his attention.  Other players’ apps insert match IDs and last move timestamps into the news feeds of their opponents after they make moves, to trigger opponents’ Data Changed events.  This is a broadcast model.

Matches

pending
match ID YYYYMMDDHHmmss-Initiator
game type (RPS/RPSSL)
target rounds : 3
target players : 2
players
player 1 ID : true
...
...
running
match ID YYYYMMDDHHmmss-Initiator : true
match ID YYYYMMDDHHmmss-Initiator : true
...
There are two legs to the Matches branch: pending and running, of interest to people who want to join or watch a match, respectively.


Match IDs are designed to insure uniqueness (no guids are available), for chronological cleanup, and for possible filtering by initiator player ID.  Pending matches do not yet have the required minimum number of players to start.  Once a pending match has enough players, the app of the last player to join transfers it to the Running section and removes it from the Pending section.  
Once a match completes, the last player to move removes it from the running branch.


The Initiator of a match stores the match information under his PlayerID, and he and the other Players insert their moves into that match tree as the game progresses, and monitor that subtree if they are playing or watching that match.


FireBaseDB Tags and Subtags



To allow FirebaseDB to return JSON strings for tags with subtags (/ separator),
we have to exclude spaces from our Firebase tags.  Here I have used underscores and CamelCase to highlight the words in my tags.


global FirebaseDB tags.png


TinyDB tags

CURRENTPLAYERID
CURRENTMATCHID
MATCHES - a list of this owner’s matchIDs, hosted or not

TinyDB Tags.png

App Dialogs

Initialization

globals


Screen1.Initialize
Screen1_Initialize.png
At Initialization time, we want to show the current PlayerID from TinyDB.  If there isn’t one, show the Registration fields.   We need to save the base FirebaseDB project bucket so that we can extend it later for newsfeed monitoring.


flush_all_fdbs
flush_all_fdbs.PNG


set_PlayerID
set_PlayerID.png


This user’s PlayerID is kept in TinyDB.  If there is no PlayerID available, expose the Register Horizontal Arrangement.


get_PlayerID
get_PlayerID.png


Status header: current playerID, newsfeed, selected matchID,  

Player Login Designer


Login / Register

Designer Dialog for Registering
Designer_Register_Dialog.png

btnRegister.Click


btnRegister_Click.png
scrub procedure
scrub.png
Anything that isn’t an upper or lower case letter or number is replaced with ‘_’.


Registering a new PlayerID is a two phase process.  All PlayerIDs are trimmed of trailing blanks, and retrieved from the PlayerNames branch of FirebaseDB.


fdbGetLogin.GotValue


fdbGetLogin_GotValue.png
If the returned PlayerID from FireBaseDB is blank, it’s a new ID, so we proceed to add it using procedure new_PlayerID.  Otherwise we alert the user.


new_PlayerID


new_PlayerID.png


Player IDs are stored as subtags under a constant FireBaseDB tag, the global PlayerNames_FDB_TAG.  The “/” starts a new JSON subtree .  The “true” value is a place holder, to be replaced by subfields later on.


The new PlayerID is taken as the current one, in TinyDB and through procedure log_signin.


References: log_signin, set_PlayerID.
log_signin


A last_login_date datetime value is kept to allow tracking and cleanup of dead PlayerIDs.
log_signin.png
login date tag values


Player FDB Tags.png
All tags, both TinyDB and FireBaseDB, are accessed through global variables, to avoid typos and to take advantage of typeblocking at block edit time.


btnHideRegister
btnHideRegister.png


A Hide button in the Register Arrangement allows the user to hide it until he requests a new PlayerID.


Menu button

btnMenuClick.png


If the user hasn’t yet picked a Player Name, he can’t ask for his running games, join a pending game, or start a new game.  The Menu button exposes a Vertical Arrangement with more action buttons.  References: get_PlayerID, HaveRunningGames.


HaveGames
HaveGames.png
The My Running Games button is disabled if the player has no running games.  Since a list is expected, we return a default value of an empty list.

Designer Menu arrangement

DesignerMenu.png



btnMyGames.Click

btnMyGames_Click.png

lpkSelectGame.BeforePicking

lpkSelectGame_BeforePicking.png

lpkSelectGame.AfterPicking

lpkSelectGame_AfterPicking.png

Reference: setMatchID

btnJoin.Click

btnJoin_Click.png
The Menu Join button does not itself do a join.  It prompts FirebaseDB for a list of pending matches that he can select from and join.


fdbGetAllPending.GotValue
fdbGetAllPending_GotValue.png


When Firebase comes back with the JSON tree of all pending games, we decode the JSON and load it into a ListView, and make it visible for selection. The Web1.JSONTextDecode block is explained at the MIT web site, http://ai2.appinventor.mit.edu/reference/components/connectivity.html#Web and also see this link for how to navigate a tree: http://ai2.appinventor.mit.edu/reference/other/xml.html.

lvwJoinGame.AfterPicking
lvwJoinGame_AfterPicking.png
A ListView Selection is forced to be text, so it has to be split and stripped to extract the gameID.
References:  joinMatch, get_PlayerID.

btnNewGame.Click

btnNewGame_Click.png

Running Matches awaiting your move

view completed rounds
make your move for the current round

Running matches awaiting other player moves

refresh button

Join a pending match

view pending matches by type
select a match
join the match


Monitor a match

fdbGameMonitor.GotValue

fdbGameMonitor_GotValue.png

fdbGameMonitor.DataChanged

fdbGameMonitor_DataChanged.png

showJSONmatch

showJSONmatch.png
References: summary, playByPlay, getMatchID.

summary



summary.png
Called by: showJSONmatch.
References: clause.


clause
clause.png
A game summary consists of  series of clauses, each with its own subkey of a match tree and a description.


Called by: summary.


playByPlay

playByPlay.png
Called by: showJSONmatch.
References: extract_players,
extract_players
extract_players.png


Called by: playByPlay.


rounds
rounds.png
Called by: playByPlay


get_winning_moves
get_winning_moves.png
Called by: playByPlay.


round
round.png
Called by: playByPlay.


announce_round
announce_round.png
Called by: playByPlay.

announce_incomplete_round
announce_incomplete_round.png


Called by: playByPlay.

ItsMyMove
ItsMyMove.png

didHePlay
didHePlay.png




announce_complete_round
announce_complete_round.png


Called by: announce_round


whatDidHePlay
whatDidHePlay.png


judge
judge.png






Rules
rules.png
Rules - RPS
Rules - RPS.png
Rules - RPSSL
Rules - RPSSL.png

Initiate a match

select game type, target rounds, target wins

Designer layout - Initiate a match
Designer - Initiate Game Layout.png


Designer components - Initiate a match
Designer_Initiate_Game_Components.png


Select a Game Type


Game Type Selection screenshot.png

Game Type List Picker blocks
Game Type Selection Blocks.png


Game Type Blurb Lookup
Blurb Lookup blocks.png

Game Type blurbs tell the moves in English.  They are stored with the rules for each game type in a list of pairs structure designed for use with the lookup in pairs block.  


The Blurb lookup is packaged in a value procedure, because it will probably happen again when it’s time to choose a move.  Notice how the lookup proceeds in opposite order (inner to outer) to the nesting of the lookup table (Rules).


getBlurb.png


Generating a unique gameID for a new game





For lack of a proper guid provider, we use a sortable datetimestamp combined with the current PlayerID, which should be unique.


We will use this as the new current match ID, accessed through set and get procedures:


createMatchID


createMatchID.png


yyyyMMDDhhmmss
yyyyMMDDhhmmss.png


setMatchID


setMatchID.png
To set the current match, we update TinyDB, identify it on the Text of it ListPicker, and set the project bucket of the FirebaseDB Game Monitor to watch the match in its owner’s matches area.


matchBucket
matchBucket.png
This bucket value homes in our db monitor to the current match.


getMatchID
getMatchID.png

Saving a pending match to FireBaseDB

pendingMatchfdbKey
The pending matches FireBaseDB path, based on RPSSL.


pendingMatchfdbKey.png
hostMatchFDBKey
hostMatchfdbKey.png
This assumes a base bucket of RPSSL.


putPendingMatch
putPendingMatch.png
For each pending match, we store its game type, target rounds, and target players, all under its matchID in the Matches/pending/ branch.  references: pendingMatchfdbKey


putHostMatch
putHostMatch.png
references: hostMatchFDBKey


btnInitiate
btnInitiate.png
A pending match is stored temporarily in the Matches/pending section as well as under the matches subsection of the initiating player.  References: getMatchID, createMatchID, putPendingMatch, putHostMatch, get_PlayerID, joinMatch


putPendingMatch

putPendingMatch.png
References: pendingMatchfdbKey


joinMatch

joinMatch.png
Joining a match is done both at the pending match section and at the home copy of the match under the originating player, and in TinyDB1 tag MATCHES.  After joining the match, we double check if the match has enough players to commence in fdbPostJoin.GotValue.


add_game
This adds a matchID to the app’s TinyDB list of matches, for display in the matchID list picker.add_game.png


hostMatchfdbKey


Reference: hostMatchfdbKey.png
hostPID
hostPID.png
The host player ID of a match is kept after the “-” in the matchID.
fdbPostJoin.GotValue
fdbPostJoin_GotValue.png
After joining a match, the match is checked if it has enough players to start its first round.  The newly looked up match is gotten from Firebase as the entire JSON string under the joined pending  matchID.  The JSON is decoded into a tree rooted at the matchID.  If enough players have joined the match, the pending match is erased from the Matches/pending leg, and added to the Matches/running leg for people who want to watch matches in progress.  All the players in this match are alerted by updating their newsfeed timestamp for this match.  References: enoughPlayers,   matchJoined , alertPlayers,


enoughPlayers


enoughPlayers.png
matchJoined
matchJoined.png


alertPlayers
alertPlayers.png
alertPlayer
This serves to alert a player by inserting a matchID and timestamp into his newsfeed.alertPlayer.png


make first move

Review closed matches

delete closed matches

quit