Archive for the 'Prototype I' Category
Team Bravo Squad – Progress Report for Prototype II: Emergi-Text System

Goals for the week: 4/3/12

Bryan’s goals for the week are to get a box built for our Emergi-Text device. He will make a model of the box first and then design the box on the computer and have the laser cutter cut the box to piece together. Once the box is built a button can be installed or made.

Programming goals: For the programming code Danny has been working on the contact list that can be used for our device. Tanner will be doctoring up his section of programming. All the code is now being shared between Tanner, Danny, and Ryan for further collaboration.

Meeting times/dates

Tuesday 1pm to 2pm

Thursday 11am to 12 pm

Individual Hours:

Bryan spent 1 to 2 hours modeling a box out of foam board and then began drawing up the box digitally for the laser cutter

Tanner spent 1 to 2 hours fixing problems with code and creating new features with our system

What we did:

We have begun final stages of our device, so full manufacturing and usability will soon be available. A box with a large easy button is being built and the final strings of code are being written.  

Where we are stuck:

Our app that we are creating will crash every so often, so we have been dealing with that and trying to figure out why the phones program this our app has less priority than other apps. When we use the push button feature the app should automatically come on and send a  message, we are having trouble with this being consistant.


Goals for the week:3/27/13

Our goals for this week were basically the same as last week. We are still working on the code for our program.

Tanner is dedicated to the code that responds to the power output of the wheelchair.

 Danny is dedicated to the code for the contact list for the device. 

Ryan is dedicate to the code for the button control that turns our device on.

Bryan is constructing  a larger button for easier use for the  electrical components to the device.

Meeting times/dates

Tuesday 1:00pm to 2:pm

Thursday 11:00am to 12:00pm

Individual Hours:

Tanner spent several hours 2-3 hour on programming his portion of the code

Bryan spent 1 hour setting up electrical components to the device. The usb port that goes into a power socket similar to a car’s power port was tested.

Ryan spent a couple hours getting examples of how to re-program a media button for a phone. He found several examples that may work.

What we did:

Tanner was able to get the app for the Emergi-Text system to actually function. There still needs to be some minor tweaking, but for the most part we have a working app for the device.

Bryan spent some time designing a box for the device as well as constructing a larger button for the device. The button is not completed but should be finished by next week.

What we didn’t do:

We were not able to have our program run continuously for our device. There may be an error in the code, but the app continues to crash after being turned on. The function on the phone put the media button at a higher priority than the function Tanner programed it for.

Bryan was not able to get a box built to hold all the electrical components to our device. The lab has been full this last week so space for work has been hard to find. The design for our box and button have been design, but need to be built now.


Where we are stuck:

Not stuck so much as waiting for code to be written. Bryan’s work is dependent upon Ryan’s code and in order for Danny’s code to work Ryan’s code must be written.

Bryan needs to solder a couple wires from our power source to the usb port.


[Three Musketters] – Concept Test II Results for Prototype I: [Laser Tag]

When discussing with the residents about our project they were all very excited.

  1. State the question you asked.
    • Is this a game you would like to play?
    • What would you like to see added to the game?
    • On a scale of 1 to 10, how interested are they in a game system like this?
      What would they be willing to pay for a system like this?
      How many people would play at the same time?
      What other games would they like to play that are similar?
      Do they have stationary computers to run the server software?
      Do they have mobile computers or laptops to run the server software?
      On a scale of 1 to 10 with 1 being simplest, for the server software would they prefer simple start-up or more game-play options?
      On a scale of 1 to 10, how interested are they in having game boundaries for limiting the play area?
      On a scale of 1 to 10, how interested are they in having a digital display on each client device?
      How would they like to hold or attach the client device?
      How would they like to interact with the client device?
      What additional features would they like to have?
  2. Report in general terms the feedback you received from the question. 
    • All of the respondents liked the idea.
    • Only one respondent didn’t care for the ease of wheelchair attachment (she uses a walker)
    •  The respondents are hoping for a large play area.
    •  All of the respondents would pay 200 dollars or less, the facility said they would consider purchase of a system for ‘fun days’.
    •  All of the respondents would be able to use the system easily.
  3. Summarize specific comments from respondents
    • One respondent suggested the feasibility of an add on handle for the control joystick with a trigger in it to be able to fire and move with the control stick.  If we have time this will be implemented.
[Lucky 13] – Concept Test II Results for Prototype I: [Battery Assisted Grabber]

Here’s a quick rundown of the feedback and suggestions that we got on Tuesday night:

The “Business End”

  1. The device will need a source of friction to help pick up and securely hold items.
  2. The moving arm might benefit from a wider piece of material at the end that would allow for more contact with items to be picked up.
  3. There was interest in having a means to judge how much pressure is being exerted on the object. For example, residents want to be able to securely pick up a glass without any danger of it breaking.

The Handle/Arm

  1. There is still a good deal of interest in the potential for telescoping action. Even if it is not automated, this is something to look into.
  2. A smaller/lighter motor is already in the design for Prototype 2 but of course residents expressed their desire for a lightweight device.
  3. One of the most important features will be a comfortable grip. Because residents have varying levels of dexterity it will be imperative to find a way to allow for multiple ways of gripping. One resident suggested a grip that resembled the looped handle of a mug since she has no individual use of her fingers.
  4. In order to maintain affordability, rechargeable batteries are a must. It will be important to find a balance between a battery pack that offers a good amount of power without becoming too cumbersome.

Miscellaneous Notes/Observations

  1. With this design, heavier items are very difficult to pick up (gee thanks physics). Because multiple residents have expressed interest in the ability to pick up heavier items, some method of adding leverage will need to be contemplated. This will likely be some sort of adapter to allow the device to be attached directly to a wheel chair.
  2. Multiple residents have issues with dropping their current grabber-type devices so some sort of strap would be a good addition to make.
  3. In manufacturing it will be very important to use latex-free materials in order to prevent allergic reactions.

Overall everyone seemed reasonably interested in and impressed with the grabber prototype (which was awesome considering it had recently caught on fire…) so we’re moving in the right direction!

[Team Bravo Squad #7] – Concept Test II Results for Prototype I: [GPS Locator Device]

This device will attach to your motorized wheelchair’s battery and monitor the amount of charge left. When it detects that the battery is critically low, it will automatically broadcast your geographical location to a pre-determined emergency contact, notifying them that you need assistance. For any other kinds of emergencies, there will be a manual switch that broadcasts your location to the emergency contact, in case you are in need of assistance and do not have any kind of cell phone. The device will be designed to run on low power, and recharge automatically with your chair; and its functions will be kept simple so that it requires little to no maintenance, putting emphasis on reliability when needed.

For our first Prototype, we showed how the system would work. Our device showed it was looking for a satellite. It was connected to the computer to show coordinates of the location of the device once it found a satellite. 

We didn’t have a whole lot of people stop by our table, but of those that did, we had some good feedback. 

  1. Is this something you think would be useful for the residents?

    We had 3 non-residents who don’t use a wheelchair stop by and agree that it is something people need.They say some residents don’t have cell phones and this product would be good for them. They agreed that CPRF residents are on a limited income and would need to set up a monthly payment plan to make it affordable for them. One person said they had a couple residents get stuck out in the cold all night because their wheelchairs got stuck and they had no way of communicating their emergency. We had about 3 residents stop by our table and they agreed that this is a useful product and we are doing well with it. 

  2. How much would you be willing to pay for this device? Of the 6 respondents interviewed, the 3 non-residents who don’t use a wheelchair said that this device would have to be affordable for these residents. Under $200 was the general consensus and payments plans may help. One of the non-residents said that it would probably be best to aim this device towards family and friends who worry about the residents and want to make sure they are safe, therefore, the family and loved ones would be the ones paying for it. The 3 residents that responded said the residents are on a limited income and would need something reasonable affordable. One resident said $50 for this device would be ideal. Another resident said anything under $200 would be affordable. 
  3. Where would be the best location for this device? All 6 of the 6 respondents agreed this device would work best if the switch was located on the side panel where it was not too easy to push on accident. Also, 2 of the respondents said that they would like the GPS box with satellite was somewhere out of the way and easily detachable and attachable, but would not accidentally fall off the wheelchair. 

This concept test was a success. Everyone seemed to think we were on the right track and agree it was something that can be useful. It is a device that people would invest their money in. Some things we recognized were that we needed to contact AT&T and see how they could work with us to provide our customers this emergency messaging device at a reasonable price without monthly fees. Also, we need to decide who our primary target market is, whether it is the wheelchair user or their family and loved ones. We need to continue to work on this device and how we can keep costs down. One person asked us if we had a way to let the person in the wheelchair know that someone is coming to help them. We currently do not have the system set up for this. It is something we will be working on. We want to be able to send them a message back letting those in an emergency  know help is on the way. Overall, it was a good experience and we learned a whole lot and we know what we need to work on and how we need to market this device. 

Team Alpha – Concept Test II Results for Prototype I: TrueView Camera System

During the second concept test,more focus was directed towards observing the interaction of CPRF members.  This proved to be far less structured than directly asking questions, but provided spontaneous feedback which I feel is more valuable for this stage of development.

Only a small number of residents were asked specific questions (4 residents).  Remaining feedback was provided as a result of spontaneous questioning or comments.

  1. Answers to specific questions
    •  Which feature of this product most interests you?
      • 4 out of 4 residents questioned (along with almost everyone else) were very interested in the motion tracking of the Kinect sensor.
    • Can you think of any unique challenges that could be overcome by this product?
      • 2 out of 4 residents were concerned with the system’s ability to represent distances related to water. 
      •  2 out of 4 residents was interested in the ability of the system to detect edges and drop-offs.
    • What feature should be added to this product to make it more usable?
      • A number of residents (3) informed me that a distance scale added to the screen would be very beneficial.
        • (Our team had existing plans to add this functionality, but feedback will help with direction.)
        • 1 out of 4 residents expressed concerns about his ability to feel a vibration and suggested that we add the ability for the system to produce a loud sound.
      • One resident suggested looking into a solar powered charger as he did not feel comfortable with the system running off of his wheelchair’s main battery.


  2. Feedback
    • One resident made the comment that the camera should be aimed to show a little bit of the ground.  This would help him to determine if he was coming upon an object that would prohibit his safe travel.
    • 2 out of 4 residents were interested in the ability to show a splitscreen view of the distance gradients and live feed.
      • The other 2 out of 4 residents were interested in a seamless integration of the distance gradients and the live feed.
    • Almost all of the residents expressed a desire to have distance markers shown directly on objects on the screen (overlay).


  3. Comment Summary
    • Debra Hinkson feels that this system would help her when she is navigating a raised deck.  She also feels that it would help her to avoid becoming high-centered which prohibits her wheelchair from moving.
    • Debra also brought up the ability of the system to detect glass and the walls of an aquarium.  (This impressed our group very much!)
    • Ron informed us that he is unable to feel vibrations from his cell phone and would prefer an auditory means to warn him of ‘impending disaster’.
    • In regards to the distance gradient/live-feed display… Sheridan had the following to say: ‘Cool’, ‘That is nuts!’
    • Others felt that the display of technology was ‘incredible’ and proved to provoke excitement amongst many (this sounds a bit biased on my part…)
    • Joshua provided excellent feedback regarding the systems ability to detect cars coming up from behind him.  He often travels on the sides of streets and is concerned about being struck by a vehicle.
      • The distance detection capabilities of the system are limited, but cars could be seen in the live feed.  This is an interesting challenge.
    • Joshua brought to light that many residents enjoy leaning back in their wheelchair.  He feels that mounting it to the backrest of the wheelchair would not work correctly as the backrest is adjusted many times per day.  He informed us that the majority of wheelchairs have fixed armrests and suggested somehow mounting the camera to the armrest frame.
Team 5 – Concept Test Results #2 for Prototype I: Rescue Lifter

This concept test was conducted at the CPRF with all team members present.  The prototype was a hand push power lifter from CPRF modified with power driven wheels, battery, control logic features, and a harness.  The Lifter was able to be commanded (move the lifter) by either a joystick mounted on the Lifter or control logic downloaded from a PC for a predetermined path.  The lifter itself (move the harness) was able to be commanded with pre-existing controls mounted on the Lifter.  Specific interviews were not conducted, but discussions with several of the CPRF residents were conducted.  All of the residents spoken to displayed a great amount of excitement with the Lifter.  One resident who generated the idea even said “very sharp, like it, just what I had in mind.”

The common theme of the discussions was maneuverability into the harness and user-ability in general.  It seems the residents were mainly concerned with their interaction of the Lifter.  Where will the controls be located at, what device will be on me, can I reach the controls, etc, were popular concerns.  With all of the questions about the harness and type of harnesses, it seems at this point, a logical solution would be to offer several different type of harnesses that would be accustomed to the user (in a personalized sense).  The harness will need to be kept as a simple interchangeable component to not accrue the cost of several product lines.  These are all simple things and must be considered before final product.  However, the main concentration at this point should be the locating and command system (be able to locate and come to an individual who has fallen). 

OnTheFly – Concept Test #2 Results for Home Automation Framework

Due to the fluid nature of the concept test, and the movement of the residents, this concept test reflects more observations and quotations and less surveying/interviewing. More surveying/interviewing will be conducted during the third concept test.

General Usage

  • If you could use our device in your home what would be the first three things you would use it on and why?
    • 3 out of 3 residents wanted this product for their blinds and lights.
    • 2 out of 3 residents wanted this product for their (ceiling) fan.
    • One resident wanted this product to turn his computer on and off.
  • On a scale of 1 to 5, with 1 being not important at all and 5 being very important, how important is the look/aesthetics of the device to you, and why did you give that rating?
    • Out of 3 respondents the average score was a 3. All 3 respondents wanted the device to look like an integrated part of the door/lamp/fan as much as possible.

Controlling the Device

  • If you were able to control the device through the internet…
    • Would you use the internet to control the device and why?
      • 3 out of 3 wanted the internet.
      • 2 out of 3 wanted the internet for increased range/flexibility.
      • 1 out of 3 wanted the internet so they’d have one less remote to worry about.
  • If you were able to control the device via remote control…
    • Would you use the remote to control the device and why?
      • 1 out of 3 also wouldn’t mind having a remote control in case their internet wasn’t working.


  • What needs of yours is this product fixing? What important needs is it not addressing but has the potential to do so? What else should we consider?
    • “Makes my life a lot simpler around the house and it gives me the ability to do things I want, when I want to do them.”
    • Can we apply this to a mailbox?
    • Could you utilize the blinds concept on a pet door?
    • “I would like this product even better if you could get the blinds to go up and down, and adjust the speed settings on the fan.”
    • “I’ve wanted a product like this for years. How soon can you put this in my house?”
    • “I would like to see the control icons be more personalized; lamp picture for a lamp, fan picture for a fan, etc.”
    • “If you can get the blinds to go up and down you would eliminate the choking hazard associated with the blinds.”
    • “I wouldn’t buy this if the remote control isn’t as easy to use as the internet, since I don’t have the internet.”

-Mike Ditch Jr.

Group 9 – Prototype I Final Report: Remote Piano Pedal Controller


     As a group, we feel that everyone should be able to enjoy the things they love to do despite their limitations. Our project is designed to enable people who are unable to use their legs to operate the pedals of a piano and to be able to do so by simply attaching a motion sensor to any moving part of their body. Depending on how they move, the motion sensor will send a signal to the Arduino /microprocessor which will in turn signal the motor to rotate. The motor will be connected to a Cam that will be attached to the pedals of the piano causing it to move either up or down as desired. The parts used in this project include: An Arduino/microprocessor, 12VDC motor, potentiometer, motor shield, cam, and an accelerometer, infrared detector, or other input device.



     The system has been tested by the use of two potentiometers. One potentiometer represents the user interface. The second potentiometer is attached to the shaft of the motor. When adjustments are made to the user interface, the potentiometer sends a signal to the arduino. This signal is interpreted as a value between 0 and 1123. This value is compared with the value of the potentiometer that is connected to the motor shaft. If the interface value is lower that the motor value, the motor is prompted to rotate backward. The movement of the motor adjusts the second potentiometer downward until the two numbers match. At this point the motor stops and waits for another signal. Likewise, when the interface value is higher than the motor value, the motor is driven forward changing the value of the potentiometer until the values agree.  In this way, the position of the motor is tracked and the tendency of the postition of the motor to drift is avoided.

     Currently, an infrared distance measuring sensor unit is being used to provide an input signal. These values range from 0 to 590 and are scaled to match the motor’s potentiometer values. The input values are buffered by a capacitor installed at the output.

     The interface between the user input and the motor is the Arduino microprocessor which is loaded with a computer program that executes the logic. A motor shield is used as the Arduino only supplies  5 volts and 12 volts are required to run the motor, additionally, the polarity of the motor inputs must be reversed in order to drive the motor in both directions. This was accomplished  by the use of the H-bridge motor shield.  A wiring diagram is included below.

YouTube Preview Image



     In the design of this project, a servo system for a DC motor has been built. Code has been developed that allows the motor to interface with an external input. Several input devices have been explored and the infrared sensor is supplying useable, if not ideal values.  A variety of input sources are being explore. Initially, the use of an accelerometer was investigated. The accelerometer did not give us useable feedback. An inclinometer was tried and again the output was not adequate. The infrared sensor values are tending to jump around causing the motor to ‘chatter’. By sending the output through a capacitor this effect is being buffered somewhat.

     Overheating of the H-bridge chips is still a problem that we are dealing with. A heat sink will be installed in the next phase of design to overcome this challenge.  Additionally, an increased current to the motor will cause the motor to move faster and produce greater torque. The final design of the cam is still underway.


Group 3 – Prototype I Final Report: Battery Range Meter



Give a brief description of what you are trying to solve. Include a high-level overview of what you made, why you made it, what parts you used, and what it does.

Wheel chair users come across many issues in their day to day lives. One of the issues they have to deal with is the limited capacity of the battery on the wheel chair they use. Battery capacities are different due to many reasons including size, age or how well it is maintained. Due to these reasons, users have a hard time knowing how long he/she can use it before they have to recharge.  All wheel chairs in the market show some kind of a battery level but how does that translate into real life?  They do not display how far the wheel chair can travel before it has to recharge.

For our project, we are trying to address this issue and build a device that can display many the miles remaining on a charge. With this intention, we did some research and started finding a solution. Currently, we are relying on the battery voltage to measure the battery charge. We have collected data about the distance our chair can travel and how the voltage drops depending on the charge.  We are reading the battery voltage at a given time and calculating the distance it has remaining on the current charge.

The major components we are using:

  1. Arduino Leonardo
  2. AttoPilot Voltage and Current Sense Breakout – 90A
  3. Basic 16×2 Character LCD – Black on Green 5V
  4. Car Adapter USB Power Supply – 5VDC 650mA


Batteries and electric wheelchairs are not made equal.  In order to get accurate distance measurements for the wheelchair we used, data had to be collected.  We spend all day in a park running down the battery of our chair and taking voltage measurements along the way.  We started with the voltage of a full charge and collected measurements around every two miles we traveled to see the change.  Here is our data:

























In order to translate this into a nice equation we can use to come up with a good judge of distance remaining, we had to change our limits to not include the full charge and dead voltage measurements.  In order to accommodate for this, we don’t allow the meter to display more than 18 miles or less than 2.  Once those we removed, we used excel to find a best fit curve.  The equation uses x as the voltage and y as the miles remaining.


The Circuit:

To connect the LCD to the Arduino, you can follow this diagram below.  The circuit and a full tutorial on how to use the LCD can be found here:



To connect the AttoPilot to the Arduino:




Arduino “A0”


Arduino “GND”


Battery “+”


Battery “-“

Code sample and a demo on how to use it:

When you are done, your entire circuit should look something like the following.


In order to power the Arduino, attach the 12V-24V DC to USB converter to the battery and plug it in using your standard USB to MicroUSB cable.

The Code:

Attached is our source code with comments to tell you what the code does.



 Measuring the voltage output of a battery is a great way to get an idea of its capacity, but it is far from precise.  This project will give an estimate of the mileage but does not take in account for the battery condition and the chair’s output.  It makes an assumption the battery is in good health and you are moving at the maximum speed on a flat surface.

In the future, there are many improvements we can make.  We hope to refine our circuit by adding other factors, for example, the current to give a more accurate reading.  Currently, our equation only works on the wheelchair we tested.  Coming up with ways to generalize these equations to work with all models of wheelchairs and different types of batteries will be the end goal.

At the last minute, our AttoPilot circuit was fried.  In order to have a demo to show, we created a simple circuit that measures the voltage across different sets of resistors.  We use this voltage to display a mileage.  We attempted to use a potential meter in order to get a full range of values for the simulated charge of the battery but the voltage was too unstable to get a reading.  We also attempted to make a voltage divider that we could read the charge of an actual battery.  When we created the circuit, again, the voltage varied too much for the Arduino to get a stable reading.

JEL Group Final Report


Our problem is difficult to express briefly. First we must explain our client, Josh’s situation. Josh is wheelchair bound and unable to communicate verbally or physically. To communicate he uses a computer system (link) and navigates using a motorized wheelchair. Unfortunately due to his inability to reliably control his motor functions he is only able to consistently manipulate one input device at a time via his knee, so he is forced to chose  between communication or propulsion. To utilize his computer system he presses a Bluetooth switch that is mounted on his chair near his knee which acts as in I/O device for his computer system.    Unfortunately this device can only communicate with his computer system and another switch is needed for him to control the motion of his wheelchair thus the switches must be exchanged, this exchange of switches is something that is beyond our clients capability thus he is reliant upon the awareness and willingness of others to perform this task.

What we are trying to do is extend the freedom of our client by creating a Bluetooth smart switch that can intercept the information sent by our clients’ Bluetooth switch and delegate how the information is to be used. Via our switch we decide how to handle this information through predefined ‘modes’ which we call chair mode and board mode. When the switch is in chair mode our switch will merely act as a relay and send the information it receives from our clients’ Bluetooth switch directly to our clients computer system. However when our switch is in board mode it will still intercept the data sent from our clients Bluetooth switch but will ignore the computer system. Our switch will then send data to our clients wheelchair which  will allow our client to utilize his computer system as well as the mobility of the chair with a single well made switch.


Currently we are pursuing two avenues that we hope will lead to a solution. Our first is a purely wireless avenue that utilizes a credit card sized Linux based computer system called a raspberry pi Raspberry Pi Official Site which has 2 usb inputs that we will use for Bluetooth capabilities. We will write preliminary Bluetooth programs in python that will interface with our clients switch and computer system. We will also make the Pi intelligent enough to switch between board and chair mode. We are utilizing the Pi because it meets our size requirements of 4x4x4 inches as well as the fact that it consumes far less power than we are limited by (5v and 1A), not to mention it is only $35 for a full powered computer. The second avenue is a semi-wireless solution that uses a circuit designed by our team member Long that incorporates an Arduino Uno.

In our Raspberry Pi solution we, presently, have only been required to build software that utilizes Bluetooth to interact with Joshs’ Bluetooth switch. Currently the only successful software we have built performs the task of ‘discovering’ nearby Bluetooth devices.

    Before we were able to build anything we needed to find out what kind of services our clients Bluetooth switch provided, we utilized several Linux tools to perform this task. (link). We also were able to obtain the Bluetooth MAC address, clock offset and class from our clients device. This information will make building the rest of the Bluetooth software much simpler.

The second avenue is a semi-wireless solution that uses a circuit designed by our team member Long that incorporates an arduino Uno. In our second solution we have built a circuit that incorporates an Arduino Uno. A diagram for the circuit can be found in the following link.  Uno Diagram

    This circuit leverages the fact that the our clients Bluetooth switch has a wired input. The three LED’s are used to represent different modes which will keep our client informed of what our device is doing. The switch, S1 in the diagram, will be the clients new switch, the input of which will be monitored by the Arduino Uno. The two modules in the diagram represent our clients Bluetooth Switch as well as a direct connection to the input of the motor of the our clients’ wheelchair. The Uno will select which module it will communicate with according to what mode the Uno is in.  When in chair mode the Arduino will be hard wired, in a sense, to the wheelchair motor. On the other hand when the Uno is in board mode the Arduino will be connected to the wired input of the bluetooth switch which will trigger the bluetooth switch to communicate with our client’s computer system via a wireless  bluetooth serial port.  


Our project has not taken the usual path. Our preliminary difficulties were largely conceptual. Just comprehending the magnitude of the impact our project would have on our client’s life took several weeks to convey to each team member as well as our instructors. After that we were burdened with several unknowns pertaining to the feasibility of intercepting information from proprietary devices while concurrently having to study the protocols utilized by bluetooth implementations. On top of all this we were only able to meet our client recently and experiment with his bluetooth switch and computer system. This meeting was fruitful and we were able to obtain the bluetooth address, class, clock offset as well as all the services provided by our clients bluetooth switch.

Despite the challenges encountered thus far and those that remain we feel that we have made consistent, although slow progress. We have had many difficulties but never pursued any options that were dead ends. Given a little more time we are extremely confident that our device will not only be a success but we will also change not only the life of our client but also positively impact his caregivers.

I have attempted to upload bluetooth python code and Uno code up to the Cratel site so that I may link to them here but have been unsuccessful, security reasons according to the post submission page. I have been attempting this for over four hours and have decided to give up. If we can get that problem fixed I will link in our code.