Today, we received a visit from Gene, a transit control solutions expert, who has designed the control system for the Automated Transit Network (ATN) known as the Bay Area Rapid Transit (BART) network that we see today, as well as one of the designers of a Personal Rapid Transit (PRT) network known as the Morgantown PRT.
In conventional transit networks, such as BART, if a tram must make a stop, the others behind it must wait. Conversely, in PRT networks, such as the Morgantown PRT, if a pod car is requested at a certain station, it will hop onto a diverging rail that circumvented the main rail, allowing the other pod cars behind it to continue along the main track. The station is referred to as an offline station because this pod car is going to make a stop, while the other pod cars continue along the main track. This diverging rail eventually merges back with the main track, so the control system must be efficient to avoid collisions.
His team’s job was and is to create and model simulations to emulate viable PRT network for certain cities. For example, he presented two notable slides, each one depicting a different track design idea. The first one consisted of two-square shaped tracks connected together by two pairs of shared offline stations on the shared side; in total there are eight offline stations. The second design idea was two T-shaped tracks conjoined at the top with the offline stations at the bottom of the T’s; in total there are six offline stations.
Following Gene’s lecture, we, the Small-Scale Team, decided to reform our track design to the second design Gene showed, the two conjoined T’s, but just making one T, as connecting a second T would be an easy for a future semester. We chose this design as it seemed the rails we currently had more closely matched.
Additionally, he wanted to see if it was a possibility to implement his control system in our project.
He provided us with some advice on how to make a reliable and efficient network that would prevent the pod cars from colliding with each other. He suggested using what he called “monuments of markers” for each pod car that can keep track of each pod car. We told him that we are using RFID tags, and he responded that those could work.
He stated that the biggest challenge is to make our system work reliably, without the need for human conductors, but instead human supervision at a central control station.
He also made a few comments for the full-scale model, but which also must be considered by the Small-Scale Team, as most of the design ideas will be tested on the small-scale model first. The real, full-scale model must balance: the capacity of the people allowed in the pod, the weight of the pod itself, infrastructure costs to build the pod, the number of pod cars that will go into individual neighborhoods, the speed of the pods, and the frequency of pods. A last note is that a good benefit-to-cost ratio (benefit/cost) must be emphasized when presenting PRT’s, such as Superway, to city leaders as well as citizens, who would be possible users. One argument that can be made to justify PRTs is: offline stations enable high traffic densities which, coupled with higher speeds, then enables PRTs to be used as a regional transportation technology.
P.S. Retired Senator Mike Honda visited as well.
---
---
We were running issues into running the gimbal motor. We weren’t using the ESC (Electronic Speed Controller) to control it because one of the websites, namely eBay, stated that it operated like a servomotor, so we assumed we could use the familiar Servo library. However, when we tried using Servo library functions such as write( ), the gimbal motor was instead twitching. Another website, namely Instructables, maintained that the gimbal is run like a servomotor, but there is another library, a modified Servo library, that exists to control the gimbal motor coupled with the ESC.
Between this week and next, I will be working on getting the gimbal motor, coupled with the ESC, to work, while David ensures proper Serial communication between the XBee on the GUI’s Raspberry Pi and the XBee on the pod car’s Arduino.
Comments
Post a Comment