Members and Communities – Page 128

Immediate issues Micro-controllers and Choice.

April 16, 2015/in Biped/by tatemcgeary

By: Tate McGeary

One of the immediate issues with the Micro BiPed showed itself in the code and micro-controller. When researching the micro-controller, it became evident that the smaller micro-controllers do not have enough memory.

The program at minimum required 14kb of flash memory and 5kb+ of dynamic memory (SRAM). In order to compensate for this, it was planned on using an ATmega 2560 micro-controller set on a custom board designed by chip45, the crumbiuno Mega. But when testing the device it immediately became evident it would not work. The primary reason was due to the inability to connect to the Arduino IDE, two different Crumbiunos™ were tested and neither worked. To eliminate hardware issues, a continuity test was done on all the components, all of which passed. The crystal itself was also tested, for if it was bad. Using the GwInstek GDS-2062 the crystal was measured; the output (pictured below) was appropriate.

The noise in the picture above is due to the flux that coated the prongs of the crystal, however despite the noise 16MHz can be seen. This means that issues with components has been ruled out, as all parts pass scrutiny.

Due to the inability to use the Crumbriuno™, it was decided to use one of the Arduino standard boards. The micro was decided on.

While the micro has a 28kb of flash memory and 2.5kb of dynamic memory (SRAM) the code could still fit if the variable declarations are moved from SRAM to flash. This can be done through the use of an Arduino function called PROGMEM when declaring variables. There were some issues using PROGMEM, see the post detailing reduction of memory.

Due note that all values for resource usage was given by Arduino IDE 1.6.1. Arduino IDE 1.6.0+ all give the SRAM usage as a dynamic memory output when a program is compiled along with flash resource usage.

Micro Processor chosen:

As explained , the initial option was the Crumbuino Mega™ however it was not possible to get the Mega to communicate with the computers at hand. So the other option was the Arduino Micro™. The primary issue with this microcontroller was lack of resources; SRAM exclusively. To compensate the project went through and reduced the variable allocation used in the program by taking out the calibration() explained in another blog. The other issue that was determined was the lack of PWM pins. PWM pins are important because the microBiPed uses 12 servos all of which need PWM impulses to move to the correct location. Yet, the Arduino Micro ™ does not have enough PWM pins, rather it has 7. To compensate for this the project is looking into using TLC5940™ ICs produced by Texas Instruments. The TLC5940 will take the necessary information from Arduino Micro™ using the appropriate library and the correct commands the TLC5940 can turn 4 PWM pins into 16.

Micro BiPed Introduction

April 16, 2015/in Biped, Biped Generation #1/by tatemcgeary

Mission Objective:

The project mission is inspired by the BiPed designed by Jonathan Dowdall of Project Biped, completed in previous semesters of EE 400D. The goal is to scale down the BiPed design by changing standard servos to micro servos to yield the μBiPed, which will result in design changes to the robot. The robot must be able to communicate and be controlled by the Axterra™ application. The final deliverable of this project is to have the µBiPed maneuver through an obstacle course, while being able to resist outside disturbances. The course may include multiple surfaces, an incline, and an obstacle avoidance portion; however, the challenges in the obstacle course may change.

Mission Profile:

The μBiPed must complete an obstacle course on a figure 8 track in ~ 7 minutes. The obstacle course will require the μBiPed to cross over a threshold, at approximately a 45° angle and a 2 cm height. From there the μBiPed must ascend an incline that is initially an 8° slope which then decreases to a 6° slope. Half way through the course the μBiPed must then start its descent down the incline towards the threshold again crossing over it at about a 45° angle proceeding towards its start position until an object (i.e. a wall) causes the μBiPed modify its path. Additionally the μBiPed must be able to withstand external disturbances. Finally the μBiPed must be able to traverse multiple types of surfaces which will include carpet, linoleum tile, and metal. All of this must be completed while using the Arxterra™ interface as per requirements. It has also been specified that microServos must be used.

*The above diagram was created in AUTOCAD™ 2014.

*Measurements were provided by the microSegway group, and confirmed by the microBiPed group.

Mission Objective and Level 1 Requirements

March 8, 2015/in Communites, Members and Communities, UFO, UFO Generation #4/by Larry Harmon

By Ayaka Hatori, Project Manager — TEST

Hello and welcome to UFO – AbDucted!

Mission Objectives:

The UFO-AbDucted team is hard at work to create a product that will resemble a UFO from the 1951 movie The Day the Earth Stood Still, which is small enough to land in the palm of one’s hand. The UFO will fly for two minutes in an unobstructed field at a height greater than 8 feet while a light show plays for the duration of the flight.

Requirements:

Level 1

1. The UFO will resemble a UFO from the 1951 movie The Day the Earth Stood Still.

Test: The final product will be visually compared against an image of the UFO from the movie to verify likeliness.

2. The UFO will fly at a height of 8 feet or higher for a minimum of two minutes.

Test: The UFO flight height will be measured against a calibrated 8 foot long object and the entire flight time will be video recorded to verity that it has met the minimum flight time requirement.

3. The UFO will be small enough to land safely in the palm of the hand.

Test: The UFO will be held in the hand comfortably without it falling off.

4. The UFO will display a light show for the duration of the flight.

Test: The UFO will have a colorful light show displayed from the bottom of the craft while it is in flight.

5. The UFO will be fully controllable on the x, y, and z axes through interfacing with the Arxterra application on an Android device.

Test: The UFO will receive communication signals from the application via bluetooth and correctly perform the dictated movements.

Arxterra Now Supports Waypoint Navigation

November 15, 2014/in Arxterra App, Getting Started/by Jeff Gomes

ArxRobot version Alpha 0.1.62 has been uploaded to Google Play at https://play.google.com/apps/testing/air.com.arxterra.arxrobot.

Changes include:

Added support for Waypoint Navigation. If you program your Arduino to take current GPS location and heading data, and navigate to a desired location, ArxRobot will:
- Provide current coordinates from its GPS sensor.
- Provide heading information from its motion sensors.
- Relay waypoint coordinates and various route management commands as the pilot triggers them at the Control Panel.
Added watchdog messaging between ArxRobot and Arduino to help detect disconnects more quickly.

To inform ArxRobot that your Arduino is programmed to take advantage of the Waypoint Navigation feature, you must enable and configure it at the Capabilities screen during ArxRobot startup.

When you write your Arduino code (see an example at https://github.com/arxterra/arxrobot-firmware), you can choose between 3 different data types for the coordinates that ArxRobot sends with the WAYPOINT_COORD and WAYPOINT_MOVE commands. Your selection will depend upon the capabilities of the Arduino you are using and your desired balance between numerical precision and the accuracy (or lack thereof) of the GPS data you expect to receive.

Our current example code uses the 32-bit floating point data type, because most Arduinos available at this time do not support a 64-bit floating point data type. The following list includes a brief description and the config settings for each type.

32-bit floating point or “float”
- The current default
- Units: degrees
- Numerical precision equivalent to a resolution of about 11 meters at the equator
- Settings:
  - Waypoint Coords as Floats: ON
  - Waypoint Floats as 32-bit: ON
64-bit floating point or “double”
- Units: degrees
- Not usable on most Arduinos at this time. What is called a “double” is actually 32-bit. See http://arduino.cc/en/Reference/Double
- Numerical precision the best we offer
- All our coordinates are stored in this data type on the Control Panel and ArxRobot and in all messaging between them
- Settings:
  - Waypoint Coords as Floats: ON
  - Waypoint Floats as 32-bit: OFF
32-bit integer or ‘long”
- Units: decimicrodegrees
- See http://sloblog.io/~pdc/kbGgQRBcYsk/latitude-and-longitude-in-32-bits for more about this option
- Numerical precision equivalent to a resolution of about 1 centimeter at the equator
- Settings:
  - Waypoint Coords as Floats: OFF
  - Waypoint Floats as 32-bit: (ignored)

The Control Panel required a lot of new features to work with this. Your browser may be caching an older version. Be sure to check the lower left corner of the window, and hit “refresh” if it says anything less than version Alpha 0.1.32.

When you board your Robot, the Control Panel has a new section in the Controls pod that appears only when Waypoint Navigation is enabled. It lets you choose whether or not the Autopilot is engaged. You can create and manage waypoints at any time and they will be sent immediately to the Arduino, regardless of which mode you are in. But the Arduino should not move on its own until it receives a WAYPOINTS_ON command.

We hope the rest of the Control Panel operations are fairly self-explanatory. The question marks are tooltip triggers, and some labels also have tooltips on them. But most importantly, when in doubt about what a button does, hover over it and there will usually be a tooltip to help you out.

Click to create a waypoint.

Then you can drag it around…

Or change the numbers directly if you like.

When you’re happy with it, click Create.

To make a change, drag the waypoint marker to a new position or just click on it. In either case, the edit window pops open again for you to make any needed adjustments and confirm the change. Or you can delete the waypoint.

Operations on an entire route are accessed via the Controls pod menu. The second row, labeled “Route Management,” appears only when Waypoint Navigation is enabled.

You can import and export in JSON format, or delete the route. Again, tooltips are your friend when you get ready to do this the first time.

If you already have a list of lat/long coordinates you want to use, create 2 or 3 random waypoints on the map. Export that route by clicking the export button while holding down the Control (Command on Mac) key, so the file will be saved with line returns and indentation to make it more readable. Open the file in a plain text editor and see how it is done. If you carefully follow the pattern you see there and make a file just like it with your own coordinates, you should be able to import it into the Control Panel.

Finally, here is an example of how you can use our Custom Command feature to add autopiloting refinements. Suppose you want to be able to adjust the Robot’s speed while it is tracking down your waypoints. You can create a custom command to deal with that, and then have the Arxterra system display a slider for you to use, including the label and tooltip you want it to display, the numerical range of values your Arduino is expecting to receive, the command ID number to use, etc.

You add your code to the Arduino sketch, then let ArxRobot know about it via the Custom Command configuration screen. See how that is done in Creating Custom Commands With the Arxterra Application.

Final Project Document

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
Matthew Clegg – Computer & Control Systems
Simon Abatay – 3D Modeling & Manufacturing

Before signing off with the final document for Spiderbot, we would like to thank various members of the Robot Company in aiding with the completion of Spiderbot:

First off, we would like to thank David Gonzalez of last semester’s Hexapod project for his loan of Chop Suey for preliminary code practice.

We would like to thank Ali Etezadkhah of 3D Bioprinter and division manager of manufacturing, for allowing us use of his 3D printer for the class and for printing Spiderbot’s pieces in a timely fashion.

We would also like to thank Tommy Sanches of MC3 for his immense help in getting Spiderbot connected to Arxterra.

We would like to thank Elaine Doan of Biped for helping run tests and for guiding Spiderbot in the writing of requirements.

Finally, we would like to thank Vice President (Dr.) Larry Harmon for all of his hard work in posting countless blogs and grading presentations, despite his busy schedule.

THANKS!

A pdf file of the final document of Spiderbot can be downloaded here:

https://dl.dropboxusercontent.com/u/184627659/EE%20400D_Spiderbot_CDD.pdf

This is Project Spiderbot signing out.

Live Long and Prosper!

Spiderbot: Struggles Remembered and Suggestions

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
Matthew Clegg – Computer & Control Systems
Simon Abatay – 3D Printing & Manufacturing

Following the mass lay-off of all members of the Robot Company for Spring 2014, we remember the numerous struggles faced by Spiderbot with the following video:

http://youtu.be/1e-2mCIpM-Y

Many improvements can be done to make future Spiderbots better machines.

For one thing, connection of Spiderbot to the Arxterra Android App can definitely be helped by possibly finding a forest-like route in a different location on campus. Many issues occurred on demonstration day during the race against Rover and Hexapod. Connection was constantly dropped when multiple projects were connected to the app in the particular race course area and perhaps a location with better wifi connection might remedy that issue.

A route with a more even terrain might be helpful in preventing damage to the gears of the servo motors, as was done with one of the servos from a rear leg of Spiderbot.

A convenient trick we learned from Tien Dang, Communications member of Hexapod, was that if, when taken apart, the servo motor shows gear damage, then the motor can easily be fixed by replacing the gear, which can most likely be purchased online. This is much cheaper than purchasing a whole new servo motor.

The damage was most likely done when testing Spiderbot in the race location prior to the race, when it encountered the various branches of the course.

As for manufacturing, the individual pieces can be improved to help Spiderbot’s overall performance. For one thing, the tibia side portions of Spiderbot’s tibia pieces can be shaved down. The pieces were extended mostly for aesthetics, so if they were shaved down to the same width as the servo motors in their particular orientation, then they should function just the same and be lighter in weight in the long run.

The base of Spiderbot was ultimately very dense, causing the stance of Spiderbot to be higher than it should have been in order to support the entire piece. A wider base most likely would have allowed for a lower position and therefore, a faster sweep of the legs. Research regarding a possible ratio between the base width and leg length should be done to achieve a faster speed.

In regards to the connections of the bracket pieces, the tibia pieces were molded in a manner that made it difficult for the screws to easily tread and lock into them. Because of this, epoxy was initially used, but after testing in the grass, it proved to be too weak of an adhesive. Loctite is recommended as a better adhesive alternative to insure secure connection. That, and testing in terrains aside from grass, since the grass most likely caused some wear and tear in the servo motors from the legs getting stuck.

Purchasing stronger servos would be a good alternative to increase the speed as well, but will ultimately rack up the cost of the final project. Another thing to keep in mind in regards to cost is that creating a mold to cast 3D pieces will require a lot of material, so the initial starting price for this project is already projected to be a couple hundred dollars, so mold and cast wisely.

Good luck to all future Robot Company Projects!

Spiderbot: The Final Video

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager

With the demonstration of all projects having wrapped up, the final video for Spiderbot, created by yours truly, has dropped! The video can be viewed after clicking the following link:

http://youtu.be/5wJuN8XxtVk

Enjoy!

Project Burndown and Overview

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager

The following image displays the final overview of Spiderbot:

Due to the incomplete state of some of the tasks originally assigned, Spiderbot is only 83% complete. The slack comes from the planning and programming portions of the progress of Spiderbot. Manufacturing is labeled at 100%, since, though not done in the timely fashion that was hoped for, Spiderbot’s design came out, for the most part, as planned.

The burndown of the project can be seen in the charts below:

I did not account for many of the issues causing delays that were encountered throughout the progress of this project, so the work and task burndown plots are steeper than they should have been.

A Day at the Races

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Matthew Clegg – Computer & Control Systems

It all began earlier in the day. Group members Kristine Abatay, Simon Abatay and Matthew Clegg met early in a classroom, for a last second check to ensure everything on Spiderbot was working properly. A couple of screws were tightened and the Android phone was connected properly to the Arxterra website. The group had lunch to prepare for the race. At around 2 o’clock, Spiderbot, Hexapod, and Rover met on the predetermined course.

There was a bit of nervousness coming from all the groups. Who would come out on top? Who would be showered with glory and accolades as the victor or who would crash and burn in failure and leave bitter and dejected? Negotiations quickly took place to shorten the course with less obstacles but this did not go through because the original course was outlined in the requirements and had to be the one all of the projects would race on.

Both Spiderbot and Hexapod were fairly large, so having them all line up and race at the same time would have proven difficult. It was decided that each project would go individually and a time would be kept as it traversed the track. All of the groups had difficulty at first establishing a connection due to Wi-Fi issues but it was all eventually settled by having only one project at a time connected to the Arxterra control panel.

We (Spiderbot) got everything up and running and decided to go first. The first two steps started off well, but after that things quickly deteriorated. The pathway was on uneven ground, so with each step, Spiderbot slowly drifted to the left. Attempts to correct this did not fare well either. As it was turning, it lost footing, which caused it to collapse. It was picked up and set on course again. The next problem to arise was the servos. The rear right servo that causes the spider to lift its leg started making a horrible grinding noise with each lift. The weight of Spiderbot might have been too great for the servos to sustain for an extended period of time. At this point, it was decided to shut everything down to prevent further damage. Simon opened up the servo and found the gears inside to be busted.

The total distance traveled was roughly 6 feet at a time of around 3 minutes. Hexapod and Rover reached a further distance but did not have their share of issues. No project completed the full course. Spiderbot was defeated that day, but it was not a total loss. The knowledge learned from the track can be used by future projects for better planning and design. From the ashes, Spiderbot shall rise again like the phoenix.

Here’s a link to a video of the exciting race day!:

http://youtu.be/XNUIfEWJOmY

Weight Resource Report

May 21, 2014/in Communites, Members and Communities, Spiderbot, Spiderbot Generation #2/by arxterra

By Kristine Abatay – Project Manager
& Simon Abatay – 3D Modeling & Manufacturing

The following tables are the weight resource reports for Spiderbot.

This first table shows the various masses that we initially predicted. The masses for the parts that were 3D printed (Chassis, Femur, Tibia, Pan & Tilt) were taken from estimates provided by SolidWorks with the properly chosen materials.

This second table is the final weigh in of all of Spiderbot’s parts, with a slight estimate on the ‘Wire Mesh, Screws, etc.’ row.

Ultimately, a majority of the parts weighed much less than what was predicted. The value that did increase was the femur portion, but that is understandable seeing as to how that particular piece was designed to hold two servo motors, so more weight is welcomed in that area.

Like Us!