Tuesday, 17 May 2016

Final reflection - Michal Ogrodniczak

Technical Reflection
Work in final sprint was mainly finetuning and integration work between mechanical sub teams. The code I wrote for sprint 2 to control servo movement was mainly unchanged but I did introduce small change that resulted in big improvement. Separating servo movement looping sequence into separate fire-forget style process allows parallel  servo movement - 3 servos were able to move at the exact same time as opposed to more traditional stepped robot movement.

def move_to(self, end_pos):
  p = Process(target=move_to_process,
  self.current = end_pos

def move_to_process(pwm, current_, channel, range_, min_, end_pos):
  current = current_
  ch = channel
  while current >= end_pos:
      current -= 0.1
      dc = range_ * current + min_
      pwm.setPWM(ch, 0, int(dc))

  while current < end_pos:
      current += 0.1
      dc = range_ * current + min_
      pwm.setPWM(ch, 0, int(dc))

This approach was change from sprint 2 where I’ve used Pipe() to communicate between two processes.

servos, keyboard = Pipe()
t1 = Process(target=move_servos, args=(servos,))
t2 = Thread(target=get_input, args=(keyboard, servos))
t1.daemon = True
t2.daemon = True

while True:
  if end:
def get_input(pipe, servos):
  global end
  while True:
      x = raw_input("?")
      if x == 'q':
          end = True
      elif x == 's':
          s = Process(target=move_servos, args=(servos,))
          s.daemon = True

def move_servos(pipe):
  # servo init code
  while True:
      x = pipe.recv()
      print 'pipe', x
          arg_1, arg_2 = x.split(" ")
          servo = int(arg_1)
          dc = float(arg_2)
          # servo move code
      except ValueError as e:
          print 'breaking servo process', e

The servos that myself and Shaun worked on were working as planned after faulty one was replaced, all they needed was fine tuning to find correct duty cycle ranges. However Fellipe’s teams servo was much different beast - it wasn’t continuous movement servo type, yet it would spin over 360 degrees. It was hard for me to pinpoint why sometimes it would move counter clockwise while I wanted to move sliglty clockwise - instead of moving 60deg right it would choose to move 300deg left. Due to the fact that the servo was shared with 3rd years and they needed it for their demo and dev work I was unable to spend more time on it as it was unavailable for two days before the demo and hence the servo issue was discovered on the integration/demo day and it was too late for us to be able to solve this problem.

Project Management
As the time progressed we all were getting more comfortable with working with each other, couple tips were brought up in team meetings which also helped:
  • ‘Don’t ask “why”’ - Kamil
  • ‘Instead of saying - “yeah, but..”,  say “yeah, and..”

From teamwork perspective final sprint worked out the best - I think this is mainly because all designs were signed-off on and just needed to be done. If someone had issues with their tasks there were people willing to help as we were all in the same boat.
Doing final system integration on the very last day was a risky but necessary decision. Mostly bug free and deterministic nature of the modules were swiftly integrated with help and guidance from Kamil. Some modules were not integrated into final system, I’m not aware of exact reasons for it (beside Kivy’s eventloop messing up threading) but it was nice to see those modules demoed independently.

Personal reflection
First of all I would like to thank everybody involved as well as Jason and Mairead for allowing us to do this module as an elective. This module is very good preparation for real world work - where all us of will work in team and using new technologies/tools. It was also great opportunity to learn and apply knowledge about multiprocessing and multithreading - we had covered some of these aspects in a class in the 1st year - but debugging a deadlock and other common issues did help me to understand them much better and to use common patterns to avoid them.

Next Phase
LamPy can be improved in many ways, in my opinion my first priority would be movement - utilise all joints on the lamp to move it. This may require some design changes but it would add a lot of life to the lamp. Next step would be a user interface mounted on the head showing LamPy face, control over the lamp itself should be done through a web client or an app as it would make it more standalone unit.
Having full movement and face on the robot would be first step into representing emotions through the lamp.
Implementing a servo library that would wrap abstract over my solution could help to build up a collection of predefined movements. These could later be used as a building blocks in the Scratch IDE in effect this could improve engagement from kids when demoing and doing workshops.

Previous posts:

No comments:

Post a Comment