I'll try to see if I can't set up a meeting for you guys with the CCTA;
would be a bit more useful than the UVM bus schedule for this project.
Keep in contact (yes Mike, that means you so I can make sure the time
Christopher Anthony Tucci wrote:
> 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
> 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.
> 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,
> 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.
>> 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
>> 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.
>> 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.
>> - 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
>> - 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).
>> 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!
>> - Michael E. Karpeles
>> UVM ACM Chapter
>> CSSA Vice President
>> CSSA Secretary