Requirements

The purpose of this system is to understand the usage of the separated bike lanes in Cambridge. Jeff Parenti's presentation from Lecture 2 is available to review.

Based on this, a starting set of requirements for the system are:

1. It should measure bicycle volume (number and direction, velocity is less critical) across a variety of Cambridge separated bike paths.***
2. It should operate without being connected to line voltage.***
3. It should be installable by a technician, and should be easy to set up without requiring alteration to the roadway.***
4. It should report faults, such as battery failure, falling, vandalism, etc.**
5. It should be as inexpensive as possible, with no or minimal on-going cost.**
6. It should operate ideally at all times, though if you really want to sleep, you could do so 1am to 6am.***
7. It should communicate data wirelessly, ideally in real time.**
8. Data from a sensor node should be able to be tied to a location.***
9. It should not identify individuals.***
10. It should operate independently without user intervention or servicing for at least one year.**
11. It should be rugged and able to withstand operation across typical Cambridge weather.***
12. Multiple systems should be able to be used simultaneously.***
13. The system should present information to the end-user in a useful way.*

There is a FAQ at the end of this document that might be useful.

Specifications and Testing

A key team metric is to develop specifications along with a plan to test (or verify) that your system meets those specifications. We'll provide a draft testing plan, but the specs are up to you, and you'll want to refine the testing plan. You will be able to consult with staff and with mentors on this.

Given that this is a HW/SW system, we can anticipate specifications falling into the following classes:

• Financial
• Regulatory
• Industrial design
• Environmental resistance
• Engineering
• Security & Privacy
• Packaging
• Installation and servicing

Remember the two most important things about specifications: 1) have a process, and 2) write them down!. They are subject to update in our iterative process.

Every specification should be backed up with a testing plan for how you will demonstrate that your system achieves that spec. The testing plan should be detailed, quantitative, and verifiable. It is as important as the spec!

Here are some things to think about for different parts:

Financial

• We are not selling these systems to our partner, so one may think that cost doesn't matter. But the City of Cambridge isn't super rich, and if the BOM is 20 they could deploy them widely, maybe even 100 is ok (check!), while for $1000 it might get less adoption. All that said, what they really don't want are ongoing software costs (no SaaS here!).

• Our time to market is dictated by our class schedule.

Regulatory

• There's going to be communications here, so some regulatory requirements.
• The HW node should be able to withstand outdoor exposure all year long. Boston is hot and wet during the summer, it's super cold and sometimes snowy in the winter. Sometimes we have rain, fog, sleet, and so on.

Industrial design

• Consider how these systems will be mounted. You can mount them to a utility pole with metal banding or sign post with bolts.
• For size and weight, smaller/lighter is better, of course. A handheld device is better than toaster-sized is better than a microwave-sized.

Environmental

• Think about that outdoor exposure.

Engineering

Sensors

• You are trying to detect a relatively large object moving in a one- or two-way the bike lane. You need to detect it and determine which direction it's going. Bonus points if you can distinguish pedestrians from bikes, or can measure their velocity.
• There are a number of different possible measurement modalities. You'll want to explore some. For example, check out this doc, or Numina for inspiration.
• Bike lanes have prescribed dimenions. You'll want to become familiar with them as they will help set your specs.
• You can't drill into the asphalt. Sorry, no buried inductive loops.

Compute

• We recommend sticking with the ESP32-C3 that we introduced in lab01. You can go to a different MCU in the ESP32 family if you think you need different specs/cost. You can even go to a different MCU family, or even a SBC, but there will be less help from staff. Up to you!

Comms

• You can't assume WiFi exists.
• Cellular is an option. It's sort-of pricey, but is basically available everywhere.
• LoRa is another option for low-power long-distance comms.

Energy management

• There's no A/C line voltage around the HW nodes, nor is there a nice 5V USB port to connect to.
• You can't even rely on direct sunlight. Some mounting poles are shaded.
• You can use a battery, of course. If it needs to be changed, make sure that's easy to do.

Firmware

• What does the MCU need to do in this system? You'll want to architect the firmware so that it is easy for team members to work on different sections, easy to debug, and so on.
• The MCU will most definitely need to sleep in order to meet energy budget. See previous...

Server & analytics

• Since we're setting up a server in the psets, we recommend using that approach here. But you're not obligated to do so.

• It will be useful to overlay your data on a map.

Web front-end

• You'll want to both visualize the data, as well as make it available for use by partners.

Security and Privacy

• These systems are going to be deployed in the wild. How long with a box mounted at waist height last in the City of Cambridge? Not sure, might be good to ask. But if you mount something way up high, how will you measure?
• The City of Cambridge has a surveillance ordinance. Your project is ok because it's experimental. But keep in mind the community and their acceptance as you consider different designs.

Packaging, installation, and servicing

• How will the HW node be installed, turned on, commisioned, and debugged (which will certainly be needed)?
• We'd like to set up that HW node in May and leave it out for months, ideally without someone needing to attend to it.

FAQ

Q: Will battery have to last one year without charging?

Yes, unless you have a way of charging it.

Q: Why can't we use line voltage?

It's not readily available out in the street. It would cost several thousand dollars to bring line voltage to any random place, outweighing the cost of the system. Though light poles are wired, the cost of bringing the wires to the outside is substantial.

Q: What are considerations on cameras and privacy?

There's a Cambridge surveillance ordinance listed above. Since this is an experimental project we can still use a camera, but all processing should occur on the device. No images should leave the device.

Q: If we use a camera and do all the processing on the unit (so only bike number is sent back), is that ok?

Jeff: Yes, that is generally how our Miovision cameras work as I understand it.

Q: Can we just put a sensor on the bike lane itself, for example the strips we use to track cars?

Those are only meant for temporary use, and we cannot cut into the concrete to attach something more permanently. So no, we can't use that approach.

Q: Is there interest in tracking individual riders using the same street?

This is either really hard and/or runs into privacy concerns.

Q: Can we assume the units will have access to direct sunlight? Or will some be shaded?

Jeff: We have flexibility over where along the corridor can be placed, so we can select locations that can get direct sunlight. However my instinct tells me that for at lest a few of the locations, the sun may not be able to keep the battery charged in the winter month. That said I don’t want to eliminate solar as a power source.

Q: What materials/tools do we (or the City) have to install the units?

Jeff: The Engineers have a large set of tools, including power drills. And, if there is a tool we need but don’t have, we can purchase it. So we can handle install of the unit itself. I would like to avoid splicing of wires or any electrical work if we can.

Q: What are limits on form factor? max size?

Jeff: No limits. The ones on the market now are about the diameter of a basketball, but flat. I can’t imagine they would need to bigger than that. Size does have practical considerations, though – larger units would be less durable because they would be exposed to accidental damage, vandalism, and even wind load.

Q: Related, if mounted to a pole, are there requirements on obstructions or protrusion from the pole?

Jeff: Similar to the previous answer. It can protrude from the pole and it’s better to do so parallel to the curb. If using a sign pole, most those are installed 45 degrees from the curb, so the form of the device would need to be able to account for that.

Q: Could we mount inside the white separator poles in the separated bike lanes?

That would be a great place to locate the device, but the plastic posts would make lousy hosts. They are flimsy and frequently struck by cars. I don’t recommend using the flex posts unless the device is tiny.

Q Any legal constraints on attaching to different types of posts?

Not for any city-owned poles (sign poles and light poles). Utility poles do not belong to us so if we want to use those I would need to find out more.

Q: How to measure accuracy?

Jeff: One step I left out of the Engineering Design process in my presentation is a testing/calibration loop at the end, because we don’t need that in civil engineering. But that will be an important part of the design of these devices – we have to be confident that they work. There are a few ways we can do this. A basic way to do it is to observe them by hand – watch the data log in real time as you are standing next to it. Or we could have an established counting method take a count at the same time. I can order a spot count when the device is deployed and compare results. The second method would take a few weeks, though, to get results back, though, so putting together a means of doing the first method is recommended. On a busy bike corridor like Hampshire Street, it will not take long to assess the accuracy of the device and see where its missing units or giving false positives.

Mar 1, 2025

Q: Can we cantilever our system over the bike lane?

Jeff: Yes, but it would have to be mounted 15 feet clear over the road surface so that taller vehicles don’t hit it. The bottom of traffic signal heads are a little higher than 15 feet up, for reference. At that height, it would probably be too high for a step ladder to install. We may need a bucket truck, which I can access through my signal maintenance contract. Street light poles are maintained by the Electrical Division of DPW, so I’ll do come coordination there. I will try and get the standard spec on the poles. I even have a measuring device for objects over the road if you need to borrow it.

You could argue that no vehicles are supposed be in the bike area, much less tall ones, but we do have to design for fire apparatus, which can run over the posts to get to the curb.

There are weight and wind load considerations – the street light pole, base and foundation is designed to counter the arm holding the lamp. New forces would have to fit within its factor of safety.

Q: Is there a Cambridge-wide WiFi network available?

Jeff: There is some coverage around public buildings (https://www.cambridgema.gov/departments/informationtechnology/cpi). I don’t know what its reach is, but if one approach relies on wi-fi we can choose a location for that device near a public building.

Q: If a team chooses to use cellular to communicate, it will cost around $4/yr for each system for the data plan. Is that ok?

Jeff: Wow, I wish my data plan was that cheap. Yes, that is OK.

Q: Should the dashboard showing the data be open to the public, or do you want it password-protected (only your team has access)?

Jeff: I’m open to either. If we are looking for simplicity, it does not need to be public. If you want students to work on user interface and dashboards, that’s OK too.

That said, ultimately the public will be interested in seeing this data in some form, which can be a dashboard or open data or other. That can stay outside the scope of this project if we need it to.

Q: Is there any ability to place LoRa hotspots in some city-owned buildings?

Jeff: I’m not sure. I would need to connect you with Information Technology in City Hall. They are extremely careful about network security and I anticipate they would have a litany of questions on that and may even ask for some written agreement. We would have to consider project schedule versus the IT administration responding to and accommodating this request. I don’t know if we would get it in time, but I can inquire.

Mar 10, 2025

Q: Roughly how many bikes/hour should we expect at peak.

A: During peak travel on busy road (Hampshire St, etc.), there might be 25 bikes queued up at an intersection over a 90-sec light cycle. Once the light changes, all bikes will go thru the intersection at the same time, though primarily single file.