XYZ / Final Documentation

Note: this final XYZ documentation is written in the style of Canadian diplomatic reporting. It’s something I’ve taken from my former career and is what I turn to when I need to thoroughly explore and clarify my own thinking about something. What follows is a total account of my XYZ final.

SUMMARY: Sometimes things that start badly end well, sometimes things that start well end badly. For the Noodle of Death team, what began with enthusiasm and smiles ended in disappointment and likely broken professional relationships. The robot itself works fine and is engaging and interactive – but that only tells part of the story.

REPORT: 

2. Re-Cap of Concept: The Noodle of Death was an idea I had based on my study of martial arts. Specifically it was based on an exercise developed by Ido Portal, who used it to develop a person’s movement capabilities, as well as based on my experiences training with pool noodles in boxing. A fun title initally suggested by Shreiya, the title was actually inappropriate to our project’s actual goal: which was to facilitate life.

3. Division of Duties and Workflow: We decided to use the Make-Block Plotter (MBP) after discussion with Ben, after consideration of other options. We agreed it would be the quickest, cheapest, easiest way. Our team was initially ahead of the other groups because of our clarity of concept and because our early experiments with the MBP had yielded successful conclusions about the way the MBP moved, as well as how the noodle would need to be secured. See below how the MBP originally moved, where we concluded that we had to put it on some kind of stiff board, secured to the ceiling rafters.

4. After this we decided to divide the workflow. I would do the noodle, Tony would do the board structure to secure the MBP to the ceiling and Shreiya would work with the G shield on the code. Comment: In hindsight, I wanted to leave XYZ with a skillset on how to use code to operate an XYZ machine. I should have made this need heard in the group and advocated for more involvement with the coding part of it. 

5. The thing came together fairly well. See below documentation of the final set up of the robot:

Final robot with board attached to speedrails, which we hung from rafters. The weight was it was adequate so that it did not move from the rafters.

Attached to the ceiling with noodle contraption. PVC pipe from Home Depot + foam insulation noodle:

The key difficulty for my part, making the “noodle of death”, was that the unit kept detaching from the stepper shaft coupler after a few rotations like this:

6. The Start Of Troubles: This is where our troubles began. I asked Shrieya to show me how to adjust the rate of the Z in order to fix the problem of the noodle falling off, but she seemed to be too busy to show me how to do this. Being busy with several other side XYZ projects, despite it being two days to the final, she did not have a simple interface where a user could control the noodle, since she still had to write the processing sketch. Therefore there was no recourse but to move it with G Code through GRBL.

7. Despite her assurances, I also did not fully trust that Shrieya would have this done on time because of subtle signals she had shown me which, in my view, was the result of insufficient communication. However, what led to corrosion of confidence was when she declined to take the time to discuss how to move the Z. It is possible that I did not articulate why I needed to move the Z and she felt that I was encroaching in her domain of responsibility, perhaps I needed to impress upon her that moving the Z was critical to my solving the problem of the noodle falling off the MBP. That possibility considered, I rule this out because I would unquestioningly help another group member if asked. For me, a basic courtesy was not shown to me, not was time given to deal with the situation. Instead, I just pushed aside. Comment: In hindsight, a timeline expectation for when each feature would be completed should have been completed and strictly adhered to.

8. I successfully figured out how to change the Z rate with GRBL G code, using the $112 command to reduce the rate from 400 to 20. This reduced the sound coming from the Stepper from a strain to something more pleasant. I found it on this GRBL feed rate website: http://www.diymachining.com/grbl-feed-rate/

9. With this, the robot was complete. Shrieya did a processing sketch and we were playing around with it earlier on. That said, it was not truly “complete” since the complete version of the robot would include an interface where User would control the robot against the Player. At this point, Shrieya settled on having a processing sketch take a pre-determined set of G Code commands, which completely changes the interaction from something dynamic to something routine. However, happy that we were done enough to show the presentation, I did not raise any complaint. Here is a video of my interaction with the final robot in action a few hours before our final presentation:

10. Spring Show Let-Down: It was ultimately my fault that we didn’t get into the spring show, since I put the wrong venue option during the application process. This was unfortunate, and my group members were very displeased with me. I think, however, that some of this anger is misplaced: after all, I did send them the link an hour before submission closed (i.e. no one bothered to check it), and I find it a little unjust that admission to the show would be decided by such a technicality – especially as we did submit on time. However, I take the majority share of blame. This was disappointing but still, things went further south from here.

11. From Cracks to Fissures: From early on, Shrieya and I had a good working relationship and friendship. This friendship was the basis of our collaboration. However, from the incident with the Z feed rate fresh in my mind, Shrieya let us know she would be away from the 8th of May up until the Spring Show. In the event we got into the show, she wrote that she would just write a bunch of G code files we could cycle through on the 14th. I responded and said that I would prefer she hand the coding over to myself and Tony while she was away, and that we would continue the work in her absence. I certainly did not want a bunch of pre-programming patterns instead of an actual user interface, for the show. She responded she would be OK doing this but said that she would not be doing a P5 interface anymore. I responded by voicing, for the first time, that I found it  unacceptable that the final robot did not have even a basic user interface and that I felt she took on unnecessary side projects at the cost of this one. She did not respond to this email. A few days later, when we spoke about this to clear the air, while I don’t feel it right to document the contents on that conversation I must say that what was initially meant to be a confidence-building conversation became antagonistic and the state of relations between Shireya and I declined significantly. [Updated Comment May 14: Upon reading a book called Difficult Conversations, which talks about moving from a blame mindset to a contribution-mapping mindset, I see how both Shrieya and I contributed to the state of affairs, and I see how things could be done different. I will take these valuable lessons into the future projects.]

12. Collaboration Lessons Learned: I count the Noodle of Death as a valuable learning experience on XYZ robots but mostly on how collaboration can go wrong when expectations and roles are not clearly spelled out. While we did clearly spell out the roles, these distinctions were insufficient to the task at hand. Combined with the fact that I did not articulate my concerns earlier on (i.e. about wanting to do more coding, with shrieya’s secondary projects, with what I expected for the final interface) and combined with team members non-communicative tendencies (i.e. the Z rate incident), this whole episode is a glaring reminder that hard discussion needs to happen at all stages, and that I should see past the laughter and good times to see the structure of the interaction itself. I felt I was blinded by how amusing the noodle was and failed to the see the decay underneath. Perhaps me putting in the wrong staging area was an unconscious action that revealed my dissatisfaction with this project. In any event, we did not get into the show, but I can honestly say I don’t really feel badly about it — other than letting my group members down, Tony especially, since he did his group role admirably.

13. I recently purchased a book entitled How to Have Difficult Conversations. I will be reading it over the summer and reflect on this invaluable learning experience.

XYZ / Z axis breakthrough

using this: http://www.diymachining.com/grbl-feed-rate/

I found that the $112 value in GRBL G-code controls how fast the noodle rotates. It was previously on 500, which spun way too fast for the noodle contraption. Taking it down to a value of 40 enabled it to spin without stressing the stepper or the noodle contraption.

That link also had this great super useful list of GRBL commands:

**** Connected to COM3 @ 115200 baud ****

Grbl 0.9j [‘$’ for help]
>>> $$
$0=10 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.010 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=1 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=0 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=25.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=314.960 (x, step/mm)
$101=314.960 (y, step/mm)
$102=78.740 (z, step/mm)
$110=800.000 (x max rate, mm/min)
$111=800.000 (y max rate, mm/min)
$112=350.000 (z max rate, mm/min)
$120=10.000 (x accel, mm/sec^2)
$121=10.000 (y accel, mm/sec^2)
$122=10.000 (z accel, mm/sec^2)
$130=200.000 (x max travel, mm)
$131=200.000 (y max travel, mm)
$132=200.000 (z max travel, mm)
ok

XYZ / April 4 Update

On March 31, the team met, and we experimented with the XY plotter.

This is what we discovered:

  • the XY area covered by the XY plotter is sufficient for our purposes. What is more critical is the size of the foam noodle we will be using. The XY plotter is 2 ft the foam noodle is 2ft – already that’s 4 feet radius of movement which exceeds our play area of 6ft by 6ft.
  • we hung the Makeblock Plotter with string by the ceiling and this arrangement insufficient because the weight of the plotter changes as the head moves. We will need to attach it directly on to the metal structure on the ceiling. We will email Rob to canvas for the space.
  • We determined the kind of part we will need to connect the Markblock (using the holes in the metal) to the ceiling’s metal hanging system. Tony will make a suitable block that will ensure a strong attachment.
  • We have determined it is important for the purposes of interaction that the robot have a district rotary and level-changing abilities. We flirted with the idea of just having a rotation because it would be easier, but we felt it would be compromising too much. Also, we would exclude children from the interaction if level changes were not possible. Shieya and I are coming up with ideas for a rotary/level-change system.

XYZ final project idea

 

For our final, Shreiya, Chengtao and I have decided to build a “dodge stick” game, where the objective of the game is to avoid a slow moving but relentless stick aimed at touching you. The inspiration for this came from the movement practice of Ido Portal, who famously trained UFC fighter Conor McGregor.

The X and Y of contraption will be approx. 6×6 feet in width and length. The part of it that interacts with the player will be a foam noodle that extends down from a cardboard Z that will be moved up and down by a threaded rod inside. For the safety of the player, we will ensure that no metal parts will come into contact with them. As for control, we are envisioning some kind of controller device that a Player 2 can use to guide the stick and try to touch the Player 1 who is inside the game.

See rough sketch below:

Issues to be resolved include:

-the stick portion will need to change levels AS WELL AS rotate. So it will be XYZR (R for rotation, and Z for level change). How will we make a system that allows for rotation and level changes?

-what material will we use for the gantry? None of us have much money — we are not going to shell our hundreds of $$$ for an XYZ final. How do we achieve our ends in an affordable way?

 

XY plotter

Our group (Tony Cheungtao Chan & I) was assigned to make our XY plotter into an XY gluestick plotter. Most notable was the movement of the whole body of the XY plotter revolving around the stuck gluestick.

The kit we used to make this was the XY-Plotter from Mdraw (now since discontinued from that company). It was great as a first-time exersize to see all its component parts!

Pros of the set up:

-very linear, relatively straightforward to assemble

-smooth XY motion.

Cons:

-instructions featured multiple online versions that, at times, did not match up with the hardware and was at times confusing. I got the feeling the company didn’t spend the extra 10% of energy to iron out all the details at the end.

-pen is limited in its movement and reliability.

-we had problems with the movement of the plotter that stemmed from a combination of a little warping of the metal bar and un-powering of the stepper motors. I think the conclusion was that the driver is insufficient.