Let the testing begin!

Today the design team had a wet run with version 0.1 and the polar bear puppet. It was awesome to see the polar bear move how we inputted in the application. There are some bugs, however, with the synchronization of the servo with the audio files. At the moment there seems to be problems with where the servo should start as the minimum position, which would be the mouth being closed entirely and the maximum position, which would be the mouth totally open. Some of the audio voice files had the mouth starting a little open and we couldn't seem to do anything to make it start in a closed position. Aside from that everything else seemed to work with minor difficulties. As a team we logged in some issues on Google Code which were a little tricky. I think we got a good start and i think as a team we will be able to find all the major bugs...the question will be if the implementation team will have enough time to squash them all! I am optimistic with the outcome and i think we will have something that will perform as good or better than what is out there.

Aside from the testing, I have taken on the task of making our drab and ugly GUI into something that is more pretty and fun. I discussed with some members of the implementation team last thursday about what we as design team could do and they brought up that we could actually design the pieces to the GUI. I have always dabbled in graphic design so i said i would be able to facilitate that for them. Last weekend i was able to get the zoom in and out icons completed and will be working on creating the rest in the weeks to come. For those interested I have posted below the zoom in/out icons...

Version 0.1

This week we had Version 0.1 showcased by the implementation team on Monday. It was very nice to actually see components put together to form some sort of application. My project gantt chart i made awhile back had us scheduled to receive 0.5 or close to 1.0 so 0.1 is far from that. However, it shows a lot of promise and i hope after our thursday team meeting we will have regrouped and ready to git'r done!

I had organized the design team to be ready for testing as soon as 0.1 came out but unfortunately with all the known bugs it seems pointless to test something that the implementation already knows is broken...nevertheless I have told everyone on design team to take a look at 0.1 and tinker around with it so that we are all acquainted with it when thursday comes. All three teams need to reconnect and refocus so that we can get this all done in the given time. I am confident that we will succeed.

Today I played around with 0.1 and i think it is great for what state it is at. It is by far from looking pretty but that is expected. I am skillful in the ways of graphic design and have made prototype screens for the app awhile back to communicate my ideas. I think that i may be able to use what i have created to make the GUI look less like windows crap and more "kiddish". We will see what we decide on collectively when it comes to that. There were mentions of hiring a graphic designer but i am not sure where that has gone.

I also spent tonight setting up the Google Code site for puppetronix. I took the 0.1 file and uploaded it to the Downloads section. Now everyone can download it without the google group trying to display the rar file in hex! I also started to enter some issues that i have found thus far with 0.1. Since some areas were not completed i tried to focus on things that were more solidified. Vertical lines down the timelines so that you can follow what time unit the blocks are occupying was something i saw missing. Some prompts were missing like allowing users to create characters with no names. I also took the To Do list and placed it as a wiki page on the Google Code site. Since the issues will be housed on the Google Code site i thought anything to do with improvements to the app should be hosted and discussed on Google Code and not on Google Group.

I don't think we have finalized our logo for Puppetronix so since i have posted images on most of my posts i will leave you with this logo concept i created for this project...

Turtle Turtle

Today we had a design meeting to basically get a sit rep (situation report) on everyone's tasks and to coordinate the coming weeks. Some design team members will be away for certain periods of time in July, which will make it more demanding on everyone. It seems like through the grapevine that the implementation team will have something for us to test on monday. We have pro-actively set up a bug reporting system using Google Code. Basically it is a free service where you can share code, report bugs, etc by inviting collaborators using their gmail accounts. This will make it easy for all the teams to coordinate and cooperate in the coming weeks when it comes to fixing the application for children consumption.

I had a request from Ali (Hardware Lead) to help in the design of the turtle. I had a cool idea of making the turtles head pop in and out of his shell. I had a design awhile back but never transferred it onto paper or bits. Ali wanted to use three servos for the turtle to have his mouth open, neck swivel and go up or down. That design would require 3 servos and it would be quite interesting but for the turtle i think we should really look into making the head go into the shell since the hand puppet is designed to make it possible. It didn't take me long to design something into 3-dimensions for the hardware team to use. Google Sketchup has been a great 3d application that i have already used for the Polar Bear puppet. It was a great tool to show the whole team and have everyone visualize what we were creating instead of scribbles on paper.

I hope hardware will take my design and create a turtle that will be able to pop his head in and out of his shell.

For those interested below are some screenshots of the simple design of having a neck that pops in and out. The principle behind the design is using a lever action to make the neck pop in and out. With a lever that is pivoting with a shorter and longer end it provides the ability for the servo on the shorter end be able to pivot the levers longer end, which in turn creates more travel for the neck. If the servo was connected to the longer side of the lever than less travel would be created for the neck. Therefore, it is essential to get the right ratio for the lever so that we have enough travel to get the head out and in the shell.

Polar Bear shall stand...back to hardware!

Nothing new to report on the design front. Everyone is working on their tasks to prep for what will hopefully soon be an application that we can test! We finalized the last portion of the design doc around a week ago and that was to finalize the audio functionality of the application. Allowing users to import audio and modify accordingly, if all goes well with implementation we may have the ability for users to record within the application and have them dynamically synch to servos. This would allow users to synch several servos to an audio clip and have them react to it.

I have reached out to the Hardware team to see if they are on track and need any assistance from the design team. I talked to Ali earlier today and was able to help him out in designing and creating the stand that the Polar Bear robot will stand on so it can be tested once the app is ready. The original design for the stand was not as sturdy and low profile as I would like it so we were able to design a low profile (only 2 inch) stand that allowed for the polar bear to stand on all fours and have his head positioned right. It is quite a simple design and could be used for other robots once hardware have completed them.

It was nice to see the polar bear once again and have it stand by itself and not lying around like a dead polar bear. His movements are quite realistic and should look good once we can input some commands to the servos via our application.

I would like hardware, for that added touch, get some fabric and drape the fabric on and around the stand. It would hide the stand very well and also give that professional look to the entire thing!

Cheers,

Dan

Application Demo

We had a recent demonstration of the application that we as the design team were apart of envisioning last week. The project timeline was very aggressive from the start and the implementation team were able to demo some components of the main GUI (graphic user interface). Unfortunately, I was hoping that the implementation would be further along with tying the components together into an application that resembles a working prototype. It was of no fault of the implementation team with the state of the application. Most of the design had to be done concurrently with the implementation creating the components that we knew for sure starting off that we needed.

My prior post mentioned the key elements, for example drag and drop, would be utilized so implementation could start on some of the coding right when the project starting. This put a lot on us the design team to produce a working design that the implementation could work from. The demo did demonstrate portions of the application that we designed and they demonstrated that the implementation team had the talent to produce.

Next few weeks will be a change because we are focusing on finishing the audio functionality design so that implementation can start on working on those in the weeks to come.

Design Commences

Today we had our second design meeting and made good progress with the initial requirements for the GUI. We also pinpointed some key features that we need to incorporate throughout the design:

Drag and Drop

Ability for actions to occur by dragging and dropping. It creates an environment that seems to be totally interactive and allows for children to focus on simple interactions with the application without having to memorize or utilize complex keyboard sequences.

Trial and Error Capability

The application will allow for children to create something and have it immediately play so they can see how it looks like and if something does not work they can than change it. Children usually work on the principle of trying something and if it doesn't work they adjust or try something else. This principle is vital to incorporate in the design so that they can fix errors quickly and easily without having to do it later.

Building Blocks

Utilize visual building blocks that children use to create servo actions that create movements in the animatronic puppets. Lego Mindstorm, Scratch and PicoBlocks utilize "building blocks" so children can building code that either creates robots, 2d or 3d animations. Text-based coding dominates the programming world and allows for flexibility, however, for children this is not the based way to introduce kids to programming. Building blocks allows for a simplified programming environment for kids.

Further development of the functional requirements will continue and also each design member will have the opportunity to create paper prototypes of the major GUI components to help share ideas and pick the best elements for our design.

Project Kick Off

Last class we had presentations made by everyone on concerns and topics that were relevant in the creation of a computer application that can help children create animatronic puppet shows in a kid-friendly environment. Today was the day we finally started to form our project team and also start looking into our project timeline. Essentially we have just over two months to design, implement and test our application before it will be used in Animatronic Workshops in Victoria and also Seattle. I have concerns with the time frame and the amount of work that needs to be done to make the application truly successful.

We were able to break down the project team into three groups which are:

Design

Responsible for the design of the application as a whole and also usability testing to see how the children work with the application. Furthermore, training materials and resources will have to be created by the Design team to help children use the application as smoothly as possible.

Implementation

Responsible in coding the application and also testing of the application's code etc.

Hardware

Responsible in creating animatronic puppets and finding innovative ways for incorporating lighting and speakers to the animatronic puppet shows to create a full theatrical performance. Will also do testing and other such tasks.

Everyone is designated on a team but you are able to help wherever you feel interested. I chose to be the Design Lead and take on the responsibility of making sure the design is on track and that everything will end up being feasible. It will be vital to make sure that communication is open to the other teams so that the Designers won't be too isolated from the Implementers. With such a tight schedule constant back and forth will make sure that none of our efforts go to waste.

Tomorrow will be our first design meeting to designate roles to designers and also plan our next tasks at hand for the remainder of the week.

Animatronic Polar Bear Complete

The project team was divided to partake in the creation of an animatronic chimpanzee and polar bear. Being that i am a fan of killer animals i chose to be on Team Polar Bear. Essentially, the polar bear started out as a stuffed hand puppet that you are able to stick your hand in to control the mouth of the polar bear. The purpose of animatronics is to animate the polar bear through the use of servo motors and ingenuity. This allows us to replace a human hand with some servos that can do some cool things like head tilts and move the mouth.

Today we were able to finish our animatronic polar bear. It didn't take much work with the team working on it. I estimate it took in total ~6 hours and it was really at a steady pace.

It took two sessions to complete it and after the initial session i found it hard to communicate the idea i had in my head with how the polar bear should be built. The major communication problem was because we were working in 3 dimensions and 2-dimensional sketches weren't cutting it. I had downloaded Google's SketchUp that allows you to make quick 3d models before but never had any reason to use it. So i re-downloaded it and within a couple hours I was able to knock out the following 3d model.


It helped everyone to conceptualize the idea and also to follow the same execution. The 3d model represents the "skeleton" of the polar bear. It has two servos that makes the upper jaw move up and down, and also the head to tilt side to side. The only thing left to do for the Polar Bear is to make a stand so the Polar Bear can be upright on all four legs and to test the servos and actually move our Polar Bear!

Brainstorming for Csc485B

First day of the course i did not expect that the course would be about creating a visual language for children to program animatronic robots. The project and the chance to work in a huge group sounds like a lot of fun. I will be really interested to find out the way that this project will pane out and what approach we take.

As mentioned in the first class, everyone was to think about ideas on how to tackle the project and satisfy the client as well the users. I have thought about the overall project and have come up with some fundamental ideas that the project should incorporate so that the project can be successful.

The following ideas are what i think about the initial set up of the solution:

1) It should utilize a medium which children have already experienced and are comfortable in working in. That is why the environment that children should use to visually program the robots is an interactive website. The website should take on a cartoon-style feel. Utilizing web technology should create a dynamic environment in developing whatever would be most visual to a child and still be familiar.

2) The website environment should take note that children work on the process of trying things and seeing what happens. The process of trial and error should be taken into account when creating the visual language and make it possible for children to easily create a program and than be able to almost instantly see what it does to the animatronic robot.

3) The website environment should also have the ability for children to save their programs and also share them by either emailing them to others or saving them on a memory drive so that children can share and learn from one another.

The visual language itself would really depend on the age group of the users. For younger children a language that bundles the robots actions into modules like "waving", "smiling" and other would be best. However, older children could have less abstraction so that the children can have the ability to fine tune a robots action.