kercos / pickmeup

Carpooling Telegram Bot

PickMeUp: a dynamic carpooling service

Pickmeup is a telegram bot running on GAE. Originally forked from yukuku's telebot. Take a look at the original Reddit post.

Note on the token upload

============ add a new file key.py manually (in gitignore) with containining the bot tokens and the MASTER chat_id as follows: TOKEN = '1294...' ADMIN_CHAT_ID = 13...

pickmeup's Issues

Thread Safe

Currently the system is not thread safe, no two requests are handled concurrently. As the number of users increases this may create some delay or problems (the DeadlineExceededError bug may be related to this). We need to solve this issue.
See https://cloud.google.com/appengine/docs/python/python25/migrate27#threadsafe

Introdurre la possibilità di pianificare una tratta

Da una coversazione su Telegram con RidiAllaVita, Luisa, Eleonara, Federico e Andrea:

RidiAllaVita:
Domanda: quanto tempo prima del viaggio é opportuno mettere l'avviso?! ☺️

Luisa:
Dipende…credo almeno un paio d' ore …sarebbe preferibile per potersi organizzare, se si ha bisogno di andare a fare la spesa ad esempio..altre volte forse sarebbe più rilassante saperlo già la mattina per il pomeriggio. Tutto dipende da che uso se ne fa del passaggio…

Federico S.:
inizialmente il sistema era stato pensato per passaggi dinamici in tempo reale: salgo in macchina, segnalo la mia disponibilità, vedo se c'è qualcuno nel mio tragitto che ha bisogno di un passaggio
pertanto non si poteva fare un'offerta di passaggio oltre ai 20 minuti
ora l'abbiamo aumentato a 60
ma mi sembra di capire che per alcune persone sarebbe meglio avere una cosa più pianificata... bisogna capire come mantenere le due modalità senza appesantire troppo l'interfaccia

Eleonora:
Su una grande utenza funziona ma su numeri limitati come abbiamo qui a riva arco è più difficile. bisogna anche tenere presente il target, qui non abbiamo universitari più facile lo usino minorenni o chi per qualche motivo è senza auto. secondo me servirebbe un tempo più lungo

Federico S:
grazie, mi sembra un'ottima informazione da tenere a mente per migliorare il sistema.
Avete in mente un modo semplice per coordinare un viaggio "pianificato"?

Federico:
Un conducente potrebbe impostare:

• tratta
• ora di partenza e flessibilità
  Una volta che il sistema accoppia passeggeri e conducenti sarebbe utile che ricevessero un messaggio col nickname per contattarsi a vicenda in caso di variazioni o ulteriori dettagli
  un conducente alla creazione di un passaggio potrebbe scegliere "Lunga durata" o "Immediato" come modalità. In automatico il sistema fa scadere l'offerta entro il tempo x

Andrea:
Oppure "programma" o "immediato"
Lunga durata sembra si riferisca ad altro ;)

Federico S.:
Si, mi sembra anche a me che la soluzione migliore sarebbe usare due sistemi diversi.

(Nawaz Khurshid) broadcast to people waiting at the station

Add possibility for driver to broadcast to people waiting at the station

plate/car info

allow to add in settings number of plate, car model

Lasciare una nota nella creazione dei passaggi (o nella ricerca come passeggero)

Nella creazione di un passaggio (o nella ricerca come passeggero) dare la possibilità di lasciare una breve nota.
Ad esempio da dove si parte esattamente, o dove ci si trova, come si è vestito o che macchina si ha per essere riconosciuti.

Use location

I think the following flow could bring two things: a faster interaction and infinite pickup points.

1) Driver starts

Driver is about to start driving and tell the system he is a driver. Exactly as he does in the current version. He send his position to the bot.

2) Passenger starts

Passenger is at the bus stop. He says is a passenger (as he does in the current version) and sends his location to the bot. The bot replies with an approximation of the location to the nearest bus stop (easy to do since all the data are available).

3) Destination

Passenger send his destination. How ?

• By selecting from a closed list (now he would see only ['Trento','Povo'])
• By texting it (i.e. "povo, alla malga")
• By sending a voice message

4) Waiting

Now passenger is waiting for a driver

5) About to leave

Driver is in his car and is about to leave for his way to work. He has already declared himself as a driver and has sent his position to the bot.

6) Broadcast

Driver receives a list of ALL the ride requests within a given range from his position. The item of the list he receives are tuples: (request_index,waiting_position,destination).

7) (driver_x,passenger_y)

Driver accept to satisfy one request from the list and a message is sent to the waiting passenger. The message contains also driver position and an estimation of the time it will take. The passenger request is cancelled from the list and new drivers are not going to see it.

8) Feedback

Driver leaves and stops to pickup the user. At the end both of them send a confirmation and leave a feedback.

9) Learn

The system will try to offer the best possibile order of the list by analyzing previous rides: i.e. passenger going to a specific location, particulare passengers, distance from waiting position, etc.

What do you think? Please discuss.

(Nawaz) broadcast to people waiting at the station

Add possibility for driver to broadcast to people waiting at the station

(Andrea) Chiedere a autisti e passeggeri di specificare le tratte

Ogni utente deve definire una tratta nei settaggi.
Per passeggeri una tratta è definita con una partenza e una destinazione.
Per gli autisti una tratta è definita con una partenza, una destinazione e possibili punti intermedi.
L'interfaccia degli autisti rimane invariata con l'eccezioe che la lista dei passeggeri presenta il luogo dove si trovano
L'interfaccia dei passeggeri rimane invariata con l'eccezioe che la lista degli autisti presenta il luogo dove sono partiti

Car Plate Identification

Identification of driver. Wouldn't be better to associate somehow the Targa of vehicle with driver Id. It will be known at run time only to the passenger waiting and would be really helpful to identify the correct vehicle. For e.g. sometimes driver could be on another side of the road for e.g in 'Port Aquila' with parking on other side of the road. Would be even useful if the passenger knows the targa of vehicle perhaps only last three letter for DP-MR-15TN where DP is direction to Povo- MR is (Mario Rossi)- and 15TN is the last 4 digits of targa.

What about a Human supervisor?

Imagine a scenario where there is a human talking to pickmeup users in real time:

1. passenger writes (or sends a voice message)to bot asking for a ride
2. bot forwards the message to the human
3. driver writes (or sends a voice message)to bot offering a ride
4. bot forwards the message to the human
5. Human responds to both of them

This would allow us to see what is actually happening: are there patterns? what is that users need? Are there any problems in the implementation of Pickmeup? Or there are problems in the interaction model?

The interface would be the coolest one: plain natural language. No buttons, nothing to set. Eventually an interface will be built for the human so to start annotating things and see what can be automated.

Facebook is working on something of this kind: https://www.facebook.com/Davemarcus/posts/10156070660595195.
We are still small enough to afford doing something similar: I volunteer for it.

Please disuss.

Invitare i passeggeri ad assumere (anche, ogni tanto) il ruolo di guidatori

Il sistema funziona solo se ci sono un buon numero di guidatori (chi offre passaggi).
Ecco quindi, oltra all'attenzione in generale ai guidatori, ai loro tempi e ad incentivi specifici per loro, il suggerimento per i passeggeri di "restituire il favore alla comunità" ovvero di assumere (anche, ogni tanto) il ruolo di guidatori.

Come fare?
Quando una persona ha ricevuto il passaggio, il bot potrebbe inviargli un messaggio tipo "Siamo felici che tu abbia ottenuto un passaggio! Che ne dici di prendere la macchina (se ce l'hai) uno dei prossimi giorni e offrire tu passaggi?"

Credo che dopo che si è ricevuto si sia anche un po' più propensi a dare ;)

number of seats

to be considered

• number of seats - informative

Make sure the user agreed on terms

At the current state the user can read the terms but has no way of actively confirming that he agree on using the software at his own risk.

We can either change the initial text (I.e. "While activating the bot the user agrees on...) or requests to press a button after reading the text and only then enable him to use pickmeup.

DeadlineExceededError

In certain situation, especially in broadcasting messages this error occurs.
DeadlineExceededError: The overall deadline for responding to the HTTP request was exceeded
See https://cloud.google.com/appengine/articles/deadlineexceedederrors?hl=en

(Aleandro) Change interation when no location is found

ho provato a dare l'input per il mio luogo di partenza, Borgo Valsugana. Io che seguo pickmeup so che ci sono poche stazioni, ma potrebbe essere frustrante per un nuovo utente che non è a conoscenza di questo dettaglio. Suggerimento: se possibile, quando viene dato il messaggio d'errore che non è stata trovata nessuna stazione vicino a quella desiderata sarebbe utile almeno avere una lista delle possibili stazioni, così l'utente può avere l'informazione che gli serve e decidere se può utilizzare le stazioni presenti. Just my two cents ;)

[Gaia] Modalità di scelta location

Da quello che ho visto si hanno 2 modi per scegliere lle locations:

1. seguo le istruzioni nel messaggio (premo la clip icon, etc.)
2. premo il bottone “List Bus Stops” e poi clicco su una delle fermate
    
      Le due opzioni dovrebbero avere “pari opportunità” :D. Dall’interfaccia sembra che puoi settare la start/end location SOLO seguendo le istruzioni nel msg. Allora perché non mettere 2 bottoni (“scegli da lista”, “scegli da mappa” ) e scrivere nel msg che hai 2 opzioni? Io la seconda opzione l’ho scoperta per caso…mi aspettavo solo un elenco. Poi cliccando su una riga ho visto che mi aggiungeva la fermata come start/end location. A questo punto renderei la lista anche più leggibile e metterei più spazio tra i singoli item perché con schermi piccoli è facile selezionare per sbaglio la fermata errata (esperienza personale)

Intervalli temporali di disponibilità (passeggero | conducente)

Allo "stato dell'arte" di PickMeUp penso che molte offerte\ricerche si manchino perchè serve che guidatore e passeggero si cerchino quasi nello stesso momento, rendendo improbabile che si becchino. Stando ai (pochi) grafici che ho visto le ricerche vengono annullate dopo poco che vengono inserite (come se i passeggeri creassero l'annuncio solo per vedere se ci sono già conducenti, annullando subito dopo la richiesta non trovandone).

Introdurre un intervallo di flessibilità da impostare alla creazione dell'offerta\ricerca aumenterebbe le chance che guidatori e passeggeri si trovino tra loro.
Un conducente ad esempio potrebbe creare un'offerta di passaggio ed impostare +5,+10,+15,+30 minuti (con riferimento 0 l'ora di creazione dell'offerta), gli incrementi determinano per quanto l'offerta rimane valida nel sistema, lasciando possibilità di estenderlo anche a posteriori (selezionando di nuovo un incremento questo viene aggiunto a quello precedentemente selezionato).
Un passeggero allo stesso modo può selezionare un incremento segnalando così per quanto è disposto ad aspettare per un passaggio.

Nel momento in cui due intervalli (conducente | passeggero) si accavallano temporalmente le parti vengono notificate affinché il conducente possa sapere fino a quando un eventuale passeggero è presente o al contrario affinché un passeggero possa sapere fino a quando un passaggio è disponibile.

Nel momento in cui le due parti sono state "accoppiate" dal sistema dovrebbero poter comunicare per accordarsi se completare subito il passaggio o aspettare ulteriormente (nel caso in cui un conducente voglia aspettare per altri passeggeri).
A tal proposito suggerisco come riferimento altri bot già esistenti che permettono a due persone di scambiarsi messaggi indirettamente attraverso il bot stesso.

Spero sia chiara la spiegazione 😉

repeated offers

From dashboard , it is visible the need to bridge the gap between ride offers/requests for e.g. Povo green and yellow lines, so they fall in same column.

Sometime it is missed by span of 15 mins. this depends also on other factors for e.g. marketing of the app. It is required to consider the situation of student who create a ride request after every two days and see a message "No ride offer". If it continues like this, perhaps he wont even bother to start telegram.

The suggestion is that in the system must create some repeated offers. For e.g. let say 5 drivers leaves around 18:00 everyday for Trento. Perhaps, it is good to keep these offers always in the system at least for a period of time.

Then instead of telling user about 0 ride offer, system can say something like "at the moment no ride offer but would you like to see available offers later in the day", and then display somehow these offers.

For e.g. that there are ride request at 1200 and an offer at 1300, this span of time can be bridged with this initiative, as user may do some other activity in this short span. Also the chat window will help in this scenario. in this case we should also allow user to communicate with driver if the trip is scheduled later.

unicode unequal comparison error in person name

I 14:23:50.287 {u'message': {u'date': 1447939430, u'text': u'START', u'from': {u'first_name': u'Niccol\xf2', u'id': 132293896}, u'message_id': 28543, u'chat': {u'first_name': u'Niccol\xf2', u'type': u'private', u'id': 132293896}}, u'update_id': 436464105}
E 14:23:50.315 /base/data/home/apps/s~pickmeup-telegram/5.388676785424653775/main.py:260: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
E 14:23:50.315 if (p.name != name):