Print

Print


things im worried about:
I think we should to speak to someone at the bus company and find out  
if they will let us put these things on there.

things i know nothing about:
if we do make them to keep them running why not put them on top of the  
bus and charge them with a small solar cell? does a bus move fast  
enough that we can put a fan up there grafted to one of those crank  
chargers?

things im pretty sure about:
I ride the bus pretty often, and have really never had to wait 20  
minutes at the stop(ymmv). my feeling is that we could simulate the  
routes and display the bus locations on a map(in a format that looks  
just like "Magic Bus" if we want) and our audience would assume its  
live data and be just as impressed, while we havent spent a dime.

If the buses are running late by 2 minutes (according to our site), is  
Bob  going to risk getting to the stop late on the assumption that the  
bus hasnt caught up to schedule between his between looking at the  
site and walking to the stop....i doubt it. my guess is hes going to  
get there at the time its supposed to arrive "just in case".

the job of public transport is to be on time, and they do it pretty  
well here. if the bus gets there early, it waits. you'll never miss a  
bus by getting there at or before the time its supposed to be there. i  
have never been disappointed or had my plans ruined by the bus schedule.

*so*
you know, in this crazy mixed up world we live in, it seems like a  
great idea to help people have better access to public transport, and  
any kind of planning aid we can provide them. reinventing what the  
bus-schedule ( as an interactive map with up to the minute  
information) is a fantastic idea. Trying to implement a system that  
requires _a lot_ of time, money and upkeep seems a little optimistic  
to me. When the gains to be made over a non-sensor based site are  
minimal at best, it seems like (and dont get offended) a big waste of  
time, money, and hacker brain power.

that said -

the CCTA site is LAME and is pretty much an electric pamphlet, if we  
include other buses that run downtown in our system, and allowed  
people to figure out transfers and walking directions (a la  
hopstop.com) we would be providing a much better service to the  
student body than letting them know that their bus is going to be 1.6  
minutes late.

getting hopstop functionality in our small city would be cool (and hip!)

cheers and apologies for being the guy whos saying all this,
chris



Quoting Michael Evan Karpeles <[log in to unmask]>:

> First off, excuse my spelling, in advance. It's kind of late. There are
> a few sections to this email. First part is for Chris (and all others
> interested in reading). Second part is updates -- what we've done on
> the project so far. Third part are FAQs (questions and answers from
> Andrew and Chris's emails). The last part is for everyone on how we
> should proceed.
>
> *Chris*
> You definitely have valid points. There are a few reasons why I think
> live tracking would still be a good idea (but know I am very open to
> persuasion and we should continue to discuss this). My arguments are as
> follows...
>
> Even if the buses stay pretty close to the schedule, it would be nice
> to be able to go online and check the buses location instead of waiting
> outside during the winter. I know of a lot of people who get out of
> classes and wait for more than 10 minutes for the bus to come.
>
> Secondly, the project can definitely reach a wide audience, would be
> fun to do, and wouldn't be overly difficult (or too expensive). In
> addition, I am sure people would benefit from the live bus tracking for
> the buses that take the off campus route during weekends (considering
> they only make cycles every half hour or so).
>
> I really don't think people would want to spend the time to check an
> estimation of the bus's current location, online. The point is having
> the convenience of being able to plan. Imagine just missing a bus (and
> not knowing it) and waiting 20 minutes in the cold because you thought
> it was just running a few minutes late. It would be much nicer to
> continue hacking in the lab and then run down to the bus stop 1 minutes
> before it was due for arrival.


> The project also has a cool factor which has the potential to attract
> new students, lead to future research and funding opportunities, and
> get the CSSA some publicity. This has been the first project that
> people have really been excited about and it would be nice to (in some
> shape or form) get a project of this magnitude and significance
> completed. That said, I'd be just as happy to put my time in another
> project (instead) that has the potential to reach a large number of UVM
> students, will be a challenge, and will get CSSA-ers excited.
>
> *Updates*
> Friday night we did get some work done that would be useful for us to
> reach our goals no matter which implementation of this project we
> choose (totally simulated or live tracking). Leif and I managed to get
> a mercurial repository set up and discussed plans for designing a
> testing interface. The repository can be found on Deadowl @
> /home/css/projects/CatTrack. So far, I haven't done too much with the
> website interface -- just worked on creating a basic framework. I did
> manage to hack together a really crappy threadable client script in
> python which emulates several cell phones concurrently submitting
> realistically generated data at set time intervals. So far the
> multi-threading has not been completed. It just emulates a single phone
> session. The actual thread spawning shouldn't take more than 20 minutes
> to get up an running based on the existing framework.
>
> Leif was working on creating a parent application which could send the
> generated pseudo cell phone data as a text message to the cssa@cems
> email account (via python twisted pop3). He also got a great start on a
> database schema.
>
> I tried to make very verbose messaged for commit logs (in hg) and keep
> documentation of my thought process but it would still be really nice
> to get a wiki page up. I'll look into Redmine and see what I can do.
>
> *FAQs*
> - We could hook the phones up to a permanent power source or find a way
> to hack them into a low power usage mode (sleeping with wake-up
> broadcasts)
> - We could find a way to "hibernate" them either via cron job or
> remotely (by software hacking cheap phones.
> - Students can send a text with a number representing a bus stop and
> get a message back with a time (ETA).
> - Could test it with just one or two phones and see if anyone uses it.
> - We can hide the phones on the bus or create an enclosure to prevent
> tampering or have it be near the bus driver(s).
>
> *ALL*
> I'm open to anything. Let's do some testing to see how accurate the
> pre-determined schedule is before continuing. If the buses are as
> accurate as we suspect, no reason to go overboard. Everyone agree? If
> nothing more, we at least have a good place to start.
>
> Cheers and congratulations if you made it this far!
>
> Sincerely,
> - Michael E. Karpeles
>
> -- 
> UVM ACM Chapter
> CSSA Vice President
> CSSA Secretary
> www.uvm.edu/~mkarpele