Our project is born from an issue feel by a user: Christelle. It’s very interesting because Christelle give us feedback constantly and drives the designing process with her feeling on the device. We can figure out her requirements with acceptance criteria. She is committed. Of course, the principal need for her is to eat by herself, and she gives us a lot of details and additional requirements.

Over the past two years, we have been able to meet users of electric meal assistants and experienced professionals who have been able to tell us which specifications are most important to them. Who better than the people concerned can explain their need !

 We also found design advice, in the scientific literature (see below) which has increased in recent years to strengthen our codesign approach.

We have listed below by priority:

• bring the food from the plate to my mouth
  • Serving food at my mouth
  • Pick up food in the plate
• Be controllable
  • Control the pace of the meal
  • Choose the part of the plate to eat
• Be comfortable according to the lunch time
  • Be quiet
  • Able to see the food in the plate
  • Not bulky on the table for me and people whose eating with me
• Be transportable
• Be universal
  • Use different command interface
  • Use different silverware
  • Use different plate
• Be customizable
• Keep the meal warm

                                                                                   User Need Diagram

Regarding these specifications, we chose a robot as solution that can be controlled by users with different interfaces.

We thought a mechanical design 6-axis robotic arm, 3 joints to reach positions in the space and 3 joints to give spoon orientation. Each of these joints will be animate by an actuator.

For commanding those actuators, we need a processor (brain) able to catch information command from users and send command to the actuator which needs power supply. It’s a system engineering which require skills in mechanics, electronic and computer science.

That’s why we divide the whole product idea into subsystems and beyond simply establishing requirements for those subsystems devising an order in which each subsystem must be defined. It also determines which dependencies between subsystems are needed for proper operation. You can see below our subsystem cartography.

We decide to start working on mechanical design, we established that was priority.

Because we can buy actuator on the market, use prototyping tools like Arduino board, laboratory power supply for electrical part.

Then for the software, we can use Arduino language to design an firmware and can easily be prototyped on mobile app using MIT App inventor project as user interface.

We define design input for each subsystem, which include Market Requirements which are typically the story of the product, its primary use cases and the environment where the device will be used. Product Requirements which are more of a technical understanding of what will be needed in order to achieve the use cases and working with another subsystem.

We figure out Risks associated to this sub system and verification test.

Is More Autonomy Always Better? Exploring Preferences of Users with Mobility Impairments in Robot-assisted Feeding.

T. Bhattacharjee, E.K. Gordon, R. Scalise, M.E. Cabrera, A. Caspi, M. Cakmak, and S.S. Srinivasa.

In ACM/IEEE International Conference on Human-Robot Interaction. 2020.

A Community-Centered Design Framework for Robot-Assisted Feeding Systems.

T. Bhattacharjee, M. E. Cabrera, A. Caspi, M. Cakmak, and S.S. Srinivasa.

In International ACM SIGACCESS Conference on Computers and Accessibility. 2019.

Active robot-assisted feeding with a general purpose mobile manipulator : Design, evaluation, and lesons learned

DaehyungPark, YuunaHoshi, P.Mahajan

In Robotics and autonomus systems. 2020