Orange Team!
Technical Review!
Presentation Video
ContROLL
An automatic device that limits the speed of a wheelchair going down a ramp in order to prevent uncontrolled descent and hand friction burns
Product Contract
View Product Contract in New WindowPhotos
Reviewer Feedback
Juergen Schoenstein
Feedback
You definitely have come a long way since the mock-up review! The form factors of your design (using disk brakes, the wheel attachment/detachment method etc.) are much more compelling now. But I am not clear who you have in mind as your target audience, and I'll gladly explain my confusion: Your scenario is that users will not have sufficient grip strength to slow down their chair gong down an incline. But if they lack grip strength, will they even be using this kind of wheelchair? (I could imagine that such users are better off with a powered wheelchair.) But maybe you are envisioning experienced and otherwise skilled wheelchair users, but a scenario where they find themselves facing an unexpected terrain challenge, or just a desire to have be able to "coast" down an incline, without having to expend additional work? Whatever your scenario is, it needs to be anchored in actual user research, and supported by actual user feedback. And that does NOT mean fishing for a singular person who confirms that they might like what you have to offer, but a broader, data-driven inquiry, asking as many (potential) users as possible about specifics of their routines, how often they have found themselves in a situation similar to the one you want to resolve, how the handled the situation then, etc. And do not consider the user interface to be an afterthought: How will they control the performance, how can they change settings along the ride (one incline might be acceptable, another might not be), how can you make this interface (buttons, handles, etc.) as simple and as effective as possible? Again, if you are considering people with limited hand dexterity, that design needs to be different from what people with high performance skills (but a desire for convenience and inconspicuousness, for example) might expect. The messaging of all your design components needs to be consistent.
Liz Stevens
Feedback
This was a very detailed demonstration that incorporated your user interview data and articulated your design choices very clearly. Do wheelchair users want the chair to come to a full stop on ramps or just slow down? Is there an option to keep speed constant, to avoid jerkiness for the wheelchair user? I imagine many people in wheelchairs are recovering from injuries, so they may value smoothness of the ride. Has that been explored in your user interviews?
Nathan Phipps
Feedback
Hi Orange! Very cool to see a functioning system, great work. I see four main categories for you in getting to an alpha prototype, sensing, controls, user interface and productization. Sensing and controls is not my area of expertise but it seems clear that you need higher fidelity whether with a hall effect sensor or an encoder. Getting PID working will hopefully help avoid lockups on the brakes but may also require a motor with higher fidelity. In terms of user interface and productization you'll want to think carefully through two different user stories, the end-user and the installation/maintenance service. A critical component of this device as a product is that it must fit on a number of types of wheelchairs. For a final presentation walking the audience through this custom fitting and installation process will be important to understanding the device as a product in the context of your business model. It is okay to be custom, as many devices in this space are, just think through how you will accomodate the custimization process. You may only service certain type of wheel chairs. Mechanical brakes can be fussy to install and align and need maintenance over time including new pads. Think about how these adjustments fit into your product cycle. How many components does the installer put onto the chair and how are they modular/customizable to different chairs eg custom profile clamps, adjustable clamps, elastic straps, etc. For your controls unit you can look at bike lights for ways to customize attachment to tubes; the brake mounts themselves may need stronger connections than a bike light, but similar principles can be applied. You also want to consider wiring from your controls unit to the brake mechanism, this is a good opportunity/differentiation between a mockup and a product vision. Cable management can just be zipties and a bundle of extra cable but having a thoughtful system will elevate the product. For end-user interface think about all the touch points, off/on, auto/emergency braking, charging, full charge / empty charge indicators, maintenance indicators (for example can you sense when you need new pads). Having solutions for all these touch points brings your device from mockup to product. You may want to look at the Smart Drive or other devices on the market for inspiration in productizing the system. https://medmartonline.com/max-mobility-smartdrive-mx2?utm_source=google_shopping&gclid=Cj0KCQiAj4ecBhD3ARIsAM4Q_jEBU19KCV2hM6L2d_q9um0z6o3aB8F5lwiSe9OIz3pIqS3WupOTCKgaAnGwEALw_wcB
Rich Wiesman
Feedback
While your presentation was quite extensive and you showed a great deal about what your design would/could become, the actual functionality of the braking system was simply not there for the tech review. I'm sure that it is clear to you that you need to get things fully functional over the next couple weeks, and along those lines, here are some suggestions and comments: 1. I like that you selected highly engineered bicycle components for your brakes. These components have already had a lot of engineering work to make them highly reliable and very light weight. I was curious why you chose the wire actuated disc brakes -- theses will perform fine, but the hydraulic versions have the advance of self adjusting for brake pad wear. 2. You seemed to be using an adapted bicycle tachometer for each wheel, which unfortunately, will probably not give you the filtered speed output that you need at the relatively slow wheelchair speeds. You might consider looking at common aches that use a small proximity sensor to "count" the teeth of a sprocket or gear as it turns. You would need to mount a simple sprocket or thin gear onto each wheel hub (maybe you add it to the brake rotors) and then mount the proximity sensor on a stationary (not turning) point. These tacos let you enter the number of teeth per revolution and should give you a better (and smoother) measure of your wheel speeds than the rather small number of magnets you are counting now. 3. I understood the tilt criteria, but something was clearly not working with this. When we watched you pushing the chair up the ramp, the brakes were going on and off on the working side. I suspect that the IMU you were using was very sensitive and needs some filtering so it doesn't think you are on a downward ramp when the chair gets accelerated up the ramp. This would likely get even worse with a wheelchair user pushing up a ramp with repetitive arm motions. 4. I still believe that you might want velocity feedback from both wheels and a closed loop control to make the chair brake straight. The reason given for not doing this seemed a bit questionable. That reason was that the user may need to turn while going down a ramp. If a user did want to turn while descending a ramp they would likely do this at a slowed speed which would cut out the braking system, anyway. If you don't have controlled straight braking I would be concerned that the very sort of user this device is intended for might find their chair being braked into the side of the ramp. 5. I liked that you discovered that many users would need the wheels to be easily removed and that this shouldn't add significant weight or complexity. Your solution for this seemed very good.
Sam Ihns
Feedback
Hello oranges! You've come a long way since mockups and it appeared in the review that you are all aware of some of the shortcomings of your current product embodiment (ie. adding the I and D part of your PID controller). Doing your user testing at Spaulding will be incredibly useful and you should tailor your product embodiment around it - so be prepared to discuss the form factor of your button/UI and attachment methods! I have full confidence you can tune your disc brakes to slow down the wheelchair, but translating that technology into a product people want (the main thing we want to teach in this class) needs to now become front and center. It may be valuable for you to look at previous wheelchair attachment products from this class and examine their mechanisms/embodiments and think about why they were made the way they were: you are a little low on time and have a lot to do, so innovating on successful past products will be a great help for your team in this final sprint! On an unrelated note, it was interesting to see the tires lock up in your demo and the wheelchair not lose any speed at all. Your brakes may just be less effective on dusty, waxy ramps (understandably so), but as you tune your PID make sure to be testing on as close a ramp as possible to final presentations with respect to material and slope so you can ensure your product showcases itself as well as it can onstage. On one other unrelated note, it seemed like during the review some unplanned technical challenges arose that required a minute of tuning or readjusting to fix. You were able to fix all these things, but the fixing was almost hidden from the reviewing teams. I can see how, in a traditional class environment, it is easy to see the reviewing team as an outside group peering in to your project to judge it, but in reality we are all here to be your supporters and collaborators! Going forward (not only in this class but in your professional lives), being candid about these challenges can help the staff appreciate the work you are doing and perhaps offer advice on how to better address the issues. Regardless, I'm really excited to see you all roll your way into the final presentations! Have fun :)
Lauren Futami
Feedback
Hi Orange Team! Great work on Tech Review! Although the group I was in didn't quite see a fully functioning prototype, we were able to see it on the cusp of working. I really liked the mechanical interface the team built between the wheel and chassis for easy wheel removal and thus easy device installation/removal. I can see that being a point of frustration that you've now minimized, especially if the device needs to be charged daily. And although we didn't see much of the housing, it was really helpful to see the CAD model of how you envision it being finished. I was curious about how the user will be interacting with the device and the wheelchair during a typical use cycle: where will the switch be to turn the device on and off? I think it would be good to think about whether it will it be directly on the device or if you are planning on wiring something closer to the user's hands when they are using the wheelchair. If the switch is on the device that will then sit below and behind where the user will sit, how might they be able to reach it to turn it on? And then, if you are wiring a switch within reach to the user while they are sitting in the chair, what would that look like to be within reach without being a hindrance when the user doesn't want to interact with the switch? I had assumed this whole time that the user would turn the device on before using the wheelchair and then leave it running the entire time the wheelchair was in use, but I realized I might be wrong when I heard about concerns about the power consumption (I'm not an electronics expert so I took the battery life for granted). I was also wondering about the use case you were thinking about for the device, as I remember the team saying that the focus has now switched to users will lower grip strength or a user with a normal grip strength but might have their hands full carrying something. This sounds like a good pivot, but I was just a little unclear about how this works with the team's new standard of the wheelchair not decelerating both wheels at the same rate so that the user may be able to still steer the wheelchair. If the user has a weakened grip strength, would they have the grip strength needed to manipulate the wheels into steering? And if the user has a normal grip strength but has their hands full, they wouldn't be able to steer the wheelchair anyway since their hands are preoccupied. I think the new target user and steering standard are both independently ok to have, but there is a bit of a mismatch when thinking of the two together. The team has made great strides with ContROLL, best of luck moving into this last stretch!
Josh Wiesman
Feedback
Make sure you are utilizing the entire team at this stage - don't be afraid to assign sub-teams to tackle the various sub systems. You may need to collect more data (speed in particular) to improve the performance. Collecting speed from both wheels may also be useful for even braking down hill, but could create issues on down hill turning - should be easy to adjust and compensate. Tackling uphill (making sure the system does not trigger / brake) will be really important, especially given how many users may go down curbs backwards (dont want a false trigger). Other things to think about - how the user will know the system is on vs off, the interface for the e-brake application (this will be a human factors problem more than a technical challenge), and charging the system (remember the user may have limitations physical limitations). One thing to think about for the final - how this system will be fit to a chair - will a "normal" person be able to install this themselves or will it require a 3rd party install?
Ellen Roche
Feedback
Hi Orange team. I tried to summarize some of the staff discussions and my take on things here. I hope this format is helpful and saves you some time. We are here for you for whatever you need in the next 13 days :) ● Think about sprocket/thin gear on each wheel hub ● Filter IMU ● Velocity feedback from both wheels, closed loop feedback ● Assign subteams ● Try to ensure device doesn’t trigger uphill Go Orange!