AFRo - Assisted Feeding Robot

Brief

Primary Objective

Develop a low-cost robot, to enable a user with limited motor control and/or tremors/palsy to feed themselves independently.  

Secondary Objectives

• Allow user to select between a range of plates/bowls (e.g. main meal and side dishes)
• Means to present a lightweight cup (with straw) to suitable position for drinking
• Adaptable, reusable design to enable simple conversion to alternate situations
• Scalable to a range of working volumes
• To be fabricated using commonly available parts with a minimum of custom machining
• Complex fabricated parts to be produced using common, low-cost “digital” techniques (e.g. 3D Printing, Laser Cutting, CNC Machining)
• Extensible user interface for potential integration with other control systems

Considerations

• A carer will set out plated meals in suitable locations, and take care of cleaning
• Robot will be positioned on lowered kitchen counter-top, with plates/bowls/cup arrayed around it
• User will position their wheelchair under the countertop, such that their torso is close to the countertop edge
• Robot will need to be able to present the spoon at a suitable mouth height and at a suitable distance from the edge of the countertop
• User interface will be customised and positioned by attending engineer, so will need to be simple/adaptable and connected via a lead/tether

Assumptions

• All feeding can be achieved using a spoon - established via prior art
• Food will be suitably prepared by carer, cut into bite-sized pieces and correctly positioned
• Plates will have high sides or use guards/surrounds to ensure the robot does not push food off the edge
• Food will keep warm (where relevant), so maintaining temperature and/or avoiding burning is not a requirement
• Plates will be securely positioned (e.g. non-slip mat, countersink place-holders)

Photographs

Illustration of install location for primary client:

Requirements

Intellectual Property

Final design files, source code, etc are to be open source and made available in the public domain.  

Git repo: https://github.com/Axford/AFRo

Published copy of this document: https://docs.google.com/document/d/1HDJsVby1FxGu6IQ2XBOvq7dboFC9hibPxshcKR86C0M/pub

Licensing

TBC - Options include LGPL, TAPR OHL, MIT

… or Public Domain

Prior Art

1) Neater Eater, approx £2500

Cited reference from client - issues charactised as too bulky, too expensive, limited functionality.  Various accessory options, and choice of manual or semi-automated.

http://www.neater.co.uk/eating-aid

2) Bestic, approx $4000

Portable, single-plate device with multiple accessory options.

www.bestic.se

3) Brazilian Concept (similar to Neater Eater)

https://www.behance.net/gallery/4428639/Eating-Robot-1st-Prototype-(work-in-progress)

4) Northeastern University Prototype, approx $900

University project, using a servo-based robot arm kit and bespoke control software (with face tracking).  Supports multiple bowls.  Reach borderline, torque borderline, cost borderline.

http://www.engadget.com/2012/05/24/northeastern-university-students-develop-eye-controlled-robotic-arm-to-feed-patients/

5) Korean Research Prototype

Highly functional research prototype, non-commercial.  Target cost range was $1800 - $2700.

Extremely useful research paper: http://cdn.intechopen.com/pdfs-wm/27402.pdf

6) Handy1 - University Research Prototype

http://www.techknowlogia.org/TKL_Articles/PDF/430.pdf

7) MySpoon (SECOM, Japan)

50g weight limit.

http://www.secom.co.jp/english/myspoon/index.html

8) Winsford Feeder, $3295

https://www.ncmedical.com/item_223.html

9) Meal Buddy, $3535

Supports up to 3 bowls.

http://www.pattersonmedical.com/app.aspx?cmd=getProduct&key=IF_46883

10) Mealtime Partner Dining System, $7795 (basic model)

Supports 3 “bowls” and a variety of mounting configurations.

http://mealtimepartners.com/description/description.htm

https://www.youtube.com/watch?v=R27e_qzaOok

11) Hello Spoon

Open source, child orientated, portable assisted feeding arm.   Design is based on Dynamixel servos (5DOF), and is controlled via an Android phone.  Reach/torque are limited, but design has potential to scale and could incorporate multiple plates/bowls.  Indiegogo campaign places retail at $499, parts costs <$399.

http://hellospoon.weebly.com/who-is-hello-spoon.html

https://www.youtube.com/channel/UCtfMeLETlUGEQrYLjg5y_9A

Alternate option for cup presentation:

Summary of Prior Art

Although a wide range of existing solutions are available, all of the commercial options fall far outside the target cost and many have limited functionality vs the requirements.  The majority of research prototypes also fall outside the target cost range.

However, there are a number of lessons to be gleaned from associated literature:

• Spoon presentation angle is more acceptable when at an angle to the user - i.e. approaches the users mouth from the side vs straight on.
• The spoon may need to tilt towards the user to aid them eating (this may need a range sensor to detect when the users mouth is near the spoon).

Commercial Robot-Arm Options

Several commercial options (kits and fully assembled units) have been evaluated for suitability for adaptation, none fall within the design requirements - most failing on insufficient reach, torque and non-compliant joints.

1)  Maplin Robot Arm Kit (and similar variants)

Insufficient reach, torque and non-compliant joints

http://www.maplin.co.uk/p/robotic-arm-kit-with-usb-pc-interface-a37jn?gclid=CKrTgNrSjcACFVHKtAod5UMAhQ

2)  AREXX RA1-PRO

Insufficient reach, torque and non-compliant joints

http://cpc.farnell.com/jsp/displayProduct.jsp?sku=HK01206&CMP=CPC-PLA&gross_price=true&gclid=CKze9-vSjcACFXDKtAodDTQAgg

3) Lynxmotion AL series (e.g. AL5D)

Insufficient reach (26cm), non-compliant joints

http://www.lynxmotion.com/c-130-al5d.aspx

4) Trossen WidowX

Borderline reach (35-50cm), too expensive ($1500)

http://www.trossenrobotics.com/widowxrobotarm

5) Trossen PhantomX

Borderline reach (36 - 50cm), insufficient torque (150g max), too expensive for base device ($500)

6) Palletisizing Robot 1

Reach ok (50cm radius, 40cm height), borderline torque (125g max), and a bit high on price ($294 CAD) - also lacks compliant joints (geared steppers).  Open source design, parts on thingiverse.

https://www.marginallyclever.com/shop/robot-arms/palletizing-robot-1

Design

Early CAD visual:

Design Notes

Mechanical design

• SCARA configuration to minimise joint torques, and therefore reduce moving mass and cost
• Shoulder, Elbow and Wrist joints to use Dynamixel AX-12A (circa £30 ea), supporting programmable PID, torque limits and passive mode for “teaching”
• Spoon pitch servo to use RoboBuilder SAM 3 servo - similar capabilities to Dynamixel, but lower torque and cheaper (circa £15 ea) - would be convenient to switch to Dynamixel XL-320 when it’s available in the UK
• Z-axis to utilise threadless ballscrew - a cheap, compliant solution, that also allows the axis to be exposed, as there are no safety concerns (i.e. slowly revolving smooth rod)
• Z-axis pitching torque taken through large linear bearing (LM20UU)
• Electronics to be housed in base unit, acting as minor counterweight to extended arm
• Base unit to be attached to situation specific sub-base - e.g. bolted to table, fitted to table clamp, etc
• Spoon holder to accommodate standard dessert spoons (or sporks?) - screw clamp? magnetic?

Mechanical Design Thoughts

• Probably need a cosmetic/safety cap to z-axis (e.g. to avoid eye injury)
• Ballscrew pitch can be tuned to optimise feed-rate vs torque
• Ballscrew clamping force can be tuned to optimise for safety
• Should the spoon holder incorporate a force sensor?  or are indirect torque/angle readings from the pitch/wrist servos sufficient?

Stuff to control/interface with

Dynamixel AX-12A Servo(s) x4

Stepper

Homing switch - at bottom of z, analog hall effect (to allow homing above min. position)

Limit switch? (on z) - not necessary

UI (3 button interface)

Serial interface (programming, diagnostics, command line)

Status LED - could use multi-colour for more sophisticated feedback (e.g. mode)

Piezo sounder

Modules

Forward Kinematics (where would these joint positions get me)

Inverse Kinematics (what joint positions are needed to get here)

Target generation (i.e. where does the spoon need to be)

Path planning (how to get between positions, collision avoidance)

Motion control (control the joints to follow planned path)

Safety (torque limits, collision detection)

State machine (for cyclic operations, mode changes)

User Feedback (lighting?  sound?  screen?  serial?)

Calibration (kinematic calibration, e.g. for new spoon)

Teach (teaching mode, for programming target positions)

EEPROM - load/save configuration

Sleep - puts device to sleep if no activity for xx minutes

Modes

Exclusive operating modes:

1. Teach (entered via serial command, or special key combo?  is that necessary?)
2. Use (default mode)

Functional modes

1. Eat - spoon/plate cycle, variants of spoon approach angle (e.g. plate vs bowl), diameter, location
2. Drink - pickup cup, present to set location

Locations

1 - n programmable locations, user can cycle through them or they can be directly accessed via serial.  Each location has a function associated (i.e. eat or drink), and configuration paramters.  

Eat/Drink Cycles

• Eat

• Position spoon ready for scoop (user can manipulate this state using button 3 to “rotate” plate) - “IDLE” state once positioned, i.e. food not on spoon
• Scoop and present spoon (can be aborted by pressing button 1 again, for example, if the scoop failed) - “ACTIVE” state once positioned, i.e. food may be on spoon.  Include a wipe function?  or cake-style function?

• Drink

• Position ready for picking up cup
• Pickup and present cup (button 3 can be used in this state to “twitch” the cup towards the user to re-align the straw)...  presentation should include a slight tilt towards user to help align straw
• Put down cup and retreat

Changing Location

• Pressing the change location button will cycle through the relevant locations.  For each, the robot will move to above the relevant location (at max height) and point the spoon down towards the centre-point - essentially posing the question “this one?”.  Pressing the Eat button selects the location and starts the relevant cycle.  

Hidden States

Although the user sees minimal states to the eat cycle, there are several internal states used to break the path planning into discrete stages:

1. Eat

1. Position (ends in IDLE state)

• If starting from ACTIVE state: Move away from presentation location (retreats along spoon axis, constant height) - slow
• If starting from SELECT state: Level spoon - quick
• If starting from START state:
• Move wrist to place spoon in correct orientation for next scoop, spoon flat at clearance height above plate - quick
• Tilt spoon down to target angle for scoop - quick
• Move spoon down to contact plate - medium  (validate height using hall sensor - essentially re-homing the z-axis)

2. Scoop/Present (ends in ACTIVE state)

• Moves along axis of spoon to scoop, z-axis moves down slightly, spoon tilts up slightly (configurable?) - quick movement
• Moves up to clearance height, flattens spoon (no tilt) - quick movement
• Moves to start of presentation location (i.e. spoon length away from final target, but at correct height) and in correct orientation (spoon faces user) - medium movement
• Moves to final presentation location along axis of spoon - slow movement

3. Rotate (if in IDLE, ends in IDLE)

• If in IDLE state: Keeps z-axis stationary, rotates spoon around spoon-centre by xx degrees - quick

2. Drink

1. Position (ends in READY)

• if starting from SELECT state:
• if starting from START state:
• Move to cup clearance height (probably max height) - quick
• Point spoon down - quick
• Move to “safe” location at final height (near cup) - medium
• Move to final position ready for pickup - medium

2. Pickup/present (ends in ACTIVE)

• Move up to pickup cup - slow
• Move up to presentation height - slow
• Move to pre-presentation location/orientation (i.e. spoon length away from user) - slow
• Move to final presentation location, tilt to presentation angle - slow

3. Put-down (ends in IDLE)

• Move away from user to pre-presentation location, level the cup - slow
• Move to target location, height unchanged - slow
• Move down to place cup on surface and un-hook - slow
• Move to “safe” location, height unchanged - medium
• Move to cup clearance height - quick
• Level the spoon - quick

4. Rotate (if in ACTIVE, ends in ACTIVE)

• Tilt cup towards user by xx degress - quick
• Tilt back to presentation angle - slow

3. Change location (ends in SELECT)

1. Move to max height - quick
2. Point spoon down - quick
3. Move to above centre of next location, height unchanged - medium

There is also a hidden “homing” sequence that is initiated at power-on, or before going to SLEEP

• Home:  (ends in START, next move will be to IDLE for selected location)

• Level spoon
• Move to clearance height
• Position at homing location
• Move down until homed
• Move up to clearance height

UI

• 3 button interface:

• Button 1: Eat/drink cycle
• Button 2: Change location
• Button 3: “Rotate” plate / “Re-align straw”

• What does it mean if a button is pressed whilst the robot is moving?

• Button 1 - abort sequence, move to next state in cycle immediately.
• Button 2 - if previous cycle is in idle state, then move to next location.  Otherwise do nothing (i.e. food may still be on the spoon, or cup may still be held)
• Button 3 - only functions if in relevant state of eat/drink cycle, otherwise does nothing

• Piezo sounder - audible feedback:

• Collision detected - Long beep
• HOME complete - short beep
• entering sleep - falling double beep
• waking up - rising double beep

• LED status indicator

• Solid when active
• “breathe” when asleep

Collisions

• do we need a way to avoid collisions with the local environment (e.g. microwave, wall)?
• how would the working volume be programmed?  special teach mode - e.g. trace spoon along perimeter?
• how would this info by used by the path planner?
• Basic version of this needs to avoid self-collisions - primarily spoon with z-axis
• Should also include spoon with table collisions (e.g. if spoon is pointed down, then the lowest safe z-axis height is increased!)
• all shoulder/elbow positions are safe, subject to spoon angle…    this can probably be implemented programmatically, e.g.

• Spoon angles greater than x, limit elbow angle to <y

• not sure how this works for path planning…  do we cheat and evaluate lots of points along the path checking for collisions at each?  this requires options for paths - or perhaps diff planning strategies, evaluated in priority order
• This also incorporates joint limits - i.e. collision with joint limit.  There will always be spoon orientations that are not possible for certain plate locations and/or sectors.  There needs to be a fall-back strategy for dealing with these - i.e. scoop from edge of plate/bowl to opposite side, rather than from centre to edge.  This will also complicate the spoon tilt, as it needs to go through an intermediate angle.

Forward Kinematics

Simple trig to derive wrist location/angle…  then just need to know spoon length/vertical offset to generate spoon position.

Calibration

Spoon length/vertical offset is calibrated in teach mode, by moving spoon to touch a known point on the robot base…  the forward kinematics can then resolve the wrist location/angle, and allow the spoon length/offset to be calculated.

Inverse Kinematics

Alway solved in terms of wrist position/orientation.  Can be solved for spoon position, by first setting the required spoon angle (world space), then solving for joint angles, then finally solving for wrist rotation.  IK solution will refer to current state to return the “nearest” solution in joint space.

Target Generation

For target state/cycle; determines:

• Wrist or Spoon final position/orientation

Spoon orientation is planned/updated in world space!  That doesn’t prevent spoon angles between interpolated during arm movements.

Path Planning (in world space)

Path planning only concerns wrist position.  Wrist angles are dealt with by motion control.

Given current position, target position, calculate trajectory of wrist - assumes spoon positions are linearly interpolated along world space path.  Trajectory is formed as a 3D cubic bezier.  Trajectory plus target wrist angles are placed into motion control queue.  Trajectories are formed to avoid collisions (self or world) and to avoid joint limits.

Planning strategies (in order of consideration), first option that avoids collisions is used:

• Straight line (world space)
• Arc-ish - formed to avoid joint limits (algorithmic) and traverse an approximated arc around the z-axis

Z-axis motion is always linear, with respect to bezier control value (0 → 1).

Motion Control

Motion control takes motion “tasks” from it’s queue and processes them, applying acceleration/velocity control, torque limits, etc.  Trajectories are converted into straight line segments (in joint space), with a world space velocity limit.  Then a look-ahead acceleration filter is applied to generate the executable motion path.  Straight line segments are processed real-time to update stepper/servo positions.  Use framework from Marlin!

Safety

Joint torques for all servos should be checked real-time during moves.  Servos and stepper should be deactivated when stationary - i.e. passive.  

Sleep

If no activity for xx minutes, then:

1. Cycle to IDLE for given state
2. HOME
3. De-activate servos/stepper
4. Go into “low power” mode - what does that mean?
5. Wait for button press (interrupt?)
6. Return to “full power” mode -what does that mean?
7. HOME, then do triggered action

Configuration Parameters - stored in EEPROM or ROM

• Global

• Kinematics

• Arm lengths
• Joint limits (degrees)
• Joint mapping - control parameter to degrees
• Vertical travel (z)
• Steps per mm (z)
• Vertical offset of wrist rotation axis from z-height
• Z-offset - height of z=0 above table surface
• Length of spoon
• Spoon vertical offset (from rotation axis, when level)
• Spoon horizontal offset (from rotation axis)
• Spoon calibration target position

• Clearance height - safe movement height when spoon is level
• Cup clearance height - safe movement height when spoon is pointing down
• Collision parameters - ??
• Sleep timeout
• Cup presentation tilt (degrees)
• Cup twitch tilt (degrees)
• Motion control

• Min/max torque/acceleration
• Velocity limits (slow, medium, fast) per joint
• Servo parameters

• PID params, torque settings/limits

• Look ahead queue size
• Presentation position (world space, spoon position and angle)
• Number of locations (stored in order)

• For each location:

• Type of location: Eat or Drink

• For Eat locations:

• Centre point
• Plate/bowl diameter
• Start of scoop spoon angle (downward tilt angle)
• End of scoop spoon angle
• Num sectors - how many “rotations” for full coverage of the plate
• Start spoon angle (i.e. angle of sector 0)
• Height - includes z position and also associated homing sensor reading

• For Drink locations:

• Pickup point (position and angle) - safe position is inferred from this
• Height - of READY point, including associated homing sensor value
• Presentation offset - relative to presentation position

State Parameters - NOT stored in EEPROM

• Kinematic state - position, velocity
• Selected location (index) - default: 0
• Mode:  Eat | Drink | Teach - default: EAT
• State:  Relative to mode, e.g. IDLE
• Sector: index (reset to zero when location is changed)

Power On sequence

1. Load configuration
2. Initialise state
3. HOME

Serial Interface

Provides a command line interface to control the arm, including a teaching interface.  Command set:

• eat - same as button 1
• drink - same as button 1
• nextLocation - same as button 2
• prevLocation - cycles to previous location
• rotate - same as button 3
• location <x>  // select location x
• locations [x]  // reports number of locations, or sets the number to x
• teach // enter teach mode for current mode/state, press rotate plate to complete, any other button to cancel
• teach done // complete current teach operation, same as pressing rotate plate
• teach cancel // cancel current teach operation
• calibrate // enter teach mode for spoon calibration, user is required to position center of spoon on calibration point, then press any button to confirm
• calibrate done // complete calibration
• calibrate cancel // cancel calibration

Max Step Rate Calculation

• Max rate movement would achieve full z-axis travel (400mm) in 5sec - ignore acceleration
• Assume 5mm ballscrew pitch
• 400mm / 5mm = 80 revolutions in 5sec, or 16 per second
• Stepper has 200 steps per revolution, run at 8 times micro-stepping -> 1600 steps/rev
• 16 revs/sec requires 25,600 steps/sec
• Using the variable frequency timing approach (as per grbl/Marlin), this is well within the 40kHz upper step limit

Servo Update Frequency

• Arbotix Bioloid library runs update loop at approx 30 Hz.  Seems reasonable, given fine grained control over target position and velocity.  Divisions for timer frequency = 16MHz / 1024 (max pre-scale) / 521 = 29.99 Hz

Software Architecture

Control loops and interrupts:

Key data structures:

• Stepper queue (circular buffer) of linear motion blocks (Stepper ISR)
• Servo queue (circular buffer) of linear motion blocks (Servo ISR)
• UI flags (button status’) - one-byte bitmask
• Control states, and associated parameters (e.g. currentPlate, currentSegment)
• Command queue (user inputs)

Command Queue

FIFO buffer of commands (see Serial Interface for list). Some carry parameters (e.g. change to plate no. x).  Structure of buffer entries:

• Command: byte  // from a set of command constants
• Parameter: byte  // optional, default to zero

Queue length - 10?  doesn’t need to be huge, it’s mostly there to handle multiple/rapid button presses (e.g. rotate plate) in an intuitive manner…  i.e. rapidly tapping the rotate button 5 times will cause the arm to move round 5 segments, even if all button presses happen before the first move has completed.

Setup function

• Configure pin modes
• Initialise stepper module

• Set initial parameters
• Disable motor

• Initialise Servo module

• Set initial parameters
• Configure Servos (e.g. max torque, velocity)
• Disable Servos (put in passive mode)

• Initialise general parameters (e.g. starting state)
• Initialise queues/buffers (command, motion)
• Read user configuration from EEPROM (e.g. location config)
• Push “Wake Up” onto the command queue

Main Loop Structure

• If Command Queue empty THEN wait for command (either from buttons, or via Serial)

• Pop Command from top of queue and Execute:

• Change mode

• To Eat
• To Drink
• To Sleep (Push Wake Up onto command queue before sleeping)
• To Teach

• Change state

• Relative to Mode

• Rotate plate

• Relative to Mode

Execution of these various commands (changing mode, state, etc) will comprise a combination of the following:

• Store the target state parameters (i.e. what are we changing to)
• Plan and queue up required motion blocks, execute in parallel
• Keep tabs on execution, update current state once complete, or execute appropriate abort sequence if a User Input is detected during execution

Handling User Input

• The status flags for button input, and testing for Serial input, are polled from various points in the main loop - primarily in the outer loop, and during motion execution (within individual commands)
• Upon receiving input, the command is either executed immediately if: the arm is idle OR it’s a passive command (e.g. diagnostic), otherwise it is held in a “next command” buffer.  The next command is then executed once the active command has completed.

Stepper Motion Block

Although these are loosely coupled to servo movements, they can operate using a much simpler planning/execution model (i.e. no look ahead smoothing) - since each movement can complete (z_axis velocity ending at zero), before the next move starts.  A single stepper motion block can execute in parallel with multiple servo motion blocks, and vice versa.  However, completion time of coordinated movements can’t be guaranteed by this approach.  This is unlikely to be an issue for the feeding task, but may be for future applications.  To solve: how to ensure tasks start together when they’re meant to (e.g. when far down the queue).

grbl/Marlin work by varying the interrupt timing to achieve acceleration/deceleration, combined with the potential for multiple step loops within a single ISR call (max 4).  This allows the ISR to run at a lower frequency (max/4) and minimises processing overhead.  The variable timing is achieved using the Timer1 Compare Match A interrupt, with the OCR1A registering controlling the counter target.  It ticks over at 1kHz when idle, waiting for motion blocks.  Max interrupt frequency is 10kHz.  Max step frequency (with 4 step loops) is 40kHz.  Pre-scaler is fixed at 8, yielding a 2MHz timer.  Slowest interrupt rate (OCR1A = 65535) = 30.518 Hz.

Timer values are read from a pre-computed lookup table - the table maps a required step rate to associated timer values.  There are two tables (fast and slow).  Don’t yet fully understand how the timer calculations are working, or what the values in the lookup tables are doing. 

• steps_z - total step count
• accelerate_until - index of step event on which to stop acceleration
• decelerate_after - index of step event on which to start decelerating
• acceleration_rate
• direction - flag
• millimeters - total travel of this block
• acceleration - mm/sec2
• acceleration_st - steps/sec2
• initial_rate
• final_rate
• nominal_rate
• busy - ??

NB: Requires global jerk setting

Servo Motion Block

This incorporates look ahead acceleration planning (trapezoidal), inspired by grbl/Marlin.  Servo updates occur within the Servo ISR, at 30 Hz.  Position and velocity of all servos is bulk updated.  Interrupts are re-enabled within the ISR to allow the Stepper ISR to continue.

• start_pos[joint] - start positions, servo units (not degrees)
• end_pos[joint] - end positions, servo units (not degrees)
• pos_change[joint] - change in positions, servo units
• servo_event_count - number of update events (at 30Hz)
• accelerate_until - index of update event at which to stop accelerating
• decelerate_after - index of update event at which to start decelerating
• acceleration_rate
• nominal_speed - nominal mm/sec of spoon tip in world space
• entry_speed - mm/sec - planned entry speed
• max_entry_speed
• millimeters - total travel of this block (spoon tip in world frame, integrated at update_event intervals)
• acceleration - mm/sec2
• recalculate_flag - for planner
• nominal_length_flag - for planner
• busy - ??

Thoughts:

• Should there be independent motion control blocks/queues for stepper and servo motion?   thinking yes

Machine Code

There are two prevalent industry approaches to low-level programming for industrial robotics:

• CNC machines (milling, lathing, cutting) - G-Code and equivalents (RS-274-D, ISO6983, FANUC)
• Robot arms - Proprietary language (ABB: RAPID, KUKA: KRL, etc)

There are a great number of similarities between these various languages, however, G-Code is the most common and standardised.  Fortunately, the core RADID/KRL motion commands have close equivalents in G-Code:

Most implementations support optional acceleration, look-ahead planning and some support variable path approximation (e.g. KRL CONT parameter).

Broad conceptual similarities:

To minimise the learning curve and maximise reusability of the code, AFRo’s machine language will be derived from G-Code, with the introduction of additional commands only where necessary.

Terminology

Command Structure / Syntax

Letter Addresses

G and M Codes

Future Exploration

• Voice control (e.g. http://jasperproject.github.io/) - discussed, and concluded voice control is unlikely to be suitable for many users, as their conditions limit speech.  However, it may be of interest as a generic control device, with potential application for some users, dependent on their condition.
• Morse code interface - spin-off project
• Software filtering of tremors to allow user more fine grained control of the robot arm (e.g. via a joystick), associated research:

• http://www.researchgate.net/publication/19575718_Evaluating_manual_control_devices_for_those_with_tremor_disability/file/60b7d52a686dc2da7f.pdf

• Adapting robot arm for alternate scenarios, e.g:

• Drawing/painting - cited in Handy1 research, especially beneficial for children

• Auto-detection of plate locations, food locations - could utilise face recognition for presenting spoon

• colour sensor near spoon?
• webcam, BeagleBone/RPi and OpenCV?

• Explore simple/fast approaches to minimise energy of arm trajectories, whilst capping maximum momentum of the system - i.e. minimum momentum path planning, with safety constraints.
• Mouth sensor to detect when the user has placed their mouth around the spoon - i.e. to trigger a withdrawal sequence, including tipping the spoon towards the user to aid removing food from the spoon
• G-Code interface…  for general purpose use.  Could convert machine internals to use G-Code style commands, then the higher-level application logic would generate a set of G-Code commands to complete each action.
• Myoelectric interface, ala: http://www.google.com/url?q=http%3A%2F%2Fwww.advancertechnologies.com%2Fp%2Fmuscle-sensor-v3.html&sa=D&sntz=1&usg=AFQjCNHr0iWPhOKKSohDy8PXz6jG8Ya1JA

References

Arduino

• Interrupts/timers: http://www.gammon.com.au/forum/?id=11488
• Circular buffers (refresher): http://en.wikipedia.org/wiki/Circular_buffer

Dynamixel

• Protocol: http://www.electronickits.com/robot/BioloidAX-12(english).pdf

Robotics:

• Trajectory planning of a two-link rehabilitation robot arm - interesting simplification of joint-space trajectories, using trapezoidal profile for the shoulder and triangular for the elbow: http://www.iftomm.org/iftomm/proceedings/proceedings_WorldCongress/WorldCongress07/articles/sessions/papers/A884.pdf