Author: kdramos

Team B1 Report for 02/29/2020

Addressing some of the pressing design oriented feedback received:

 

Some of the feedback we received dealt with how much fidelity the star mount could simulate actual starlight. To address this we plan to discuss the target of each subsystem test. For one, the star simulating mount does not serve the purpose of simulating actual star-light but rather the movement of stars. Since the capture device is out of scope we plan to specify certain restrictions for how much contrast there should be between an object and the “background” (space) in order to allow for accurate “object identification” (tokenization really). This threshold will be tested with generated offsets of real captures taken with a typical entry level capture device (~$700 DSLR cameras [Canon T7i or Nikon D5600]) with 55mm lenses). However, since this is out of scope our stand works with the assumption that these captures meet these metrics [A badly taken capture, for example a long exposure shot of a sodium street lamp, would not meet this].

The rest of the feedback ran along the lines of too little specification in the design presentation as well as some doubts when it comes to competitive analysis. These will all be reflected in the final draft of our design review.

 

Risks:

There is a risk that Yuyi won’t be able to work much on the circuitry and layout associated with the test setup this week, as CMU’s ECE Open House is scheduled from Tuesday to Thursday of this week. This could push our schedule back because this will leave Kenny to work individually on the circuit design for the laser drivers/motor drivers composing our project’s test setup. Fortunately, the impact of this is unlikely to jeopardize our project. Work on the CV and physical mount is still progressing and the test setup will not be needed until such is completed. Therefore, a contingency plan isn’t really required for this.

 

Thus far, we haven’t had a need to make changes to the system’s existing design. However, we intend to push the layout and fabrication of the user interface board of our project to the week of Spring Break. The task will then last until Week 9, when our team will begin integrating the CV with the mount’s motor system. The new Gantt chart is as follows:

Kenny Ramos. Status Report 02/29/2020

This week was particularly consumed by other logistic aspects of the class so I was unable to get some other things done. I wanted to finalize some of the simulation stuff to have more concrete numbers and figures for the design review as well as address some of the feedback we got from both our professors and peers and reflect that in our final design review.

 

Operational things accomplished:

 

  1. Finalized gearbox while I was unable to get the physical parts printed out this week I should be able to address this on the upcoming Monday class.
  2. Finalized turntable design for “star simulator” mount should be able to decide on final design by next week and get that into fabrication.

 

For next week the final steps to fabrication should be taken after the design review is finalized. Since our budget will also be finalized by then we hope to order every part necessary by next week as well which will allow us to start assembling after the break.

Another pressing matter is spinning up our software component development. Thankfully most of the setup work was already done in week 6 so we are able to get that done relatively quickly. After week 8 and into week 9 we should be starting on some CV prototypes for our stand, including functional astral object identification and dots(pixels) to real movement conversions.

 

Some of the risks are mostly due to schedule and some unfortunate asynchronicities in our project. Fabrication and ordering should be done by Spring break in order to account for possible travel plans or previous appointments by members of our team so not meeting that could cause real problems. This means that all of our devotion to this class should be focused on meeting that schedule goal.

Kenny Ramos’s Status update for 22 Feb. 2020

Kenny Ramos’s Status update for 22 Feb. 2020:

For this week I began setup work for computer vision and object recognition as well as the rest of the basic RPI toolchains that will be necessary for the project. Most of my time on this was spent setting up RPI, compiling libraries, setting up OpenCV, testing MTP protocols with libgphoto2, setting up cpp interfacing with libgphoto2, and some very annoying RPI quirks.

 

Compiling linux libraries and setting up RPI specific stuff is pretty mundane so I will go over the library lists needed to compile as well as some preliminary tests that I ran to make sure it responded well.

 

Libraries Used (for now):

 

Preliminary Tests:

For OpenCV testing is fairly simple since it comes with a set of examples that it is ready to run. Testing should be done later to measure performance. For libgphoto2 I simply tested compatibility with my phone (Galaxy S9 that supports [MTP](https://docs.microsoft.com/en-us/windows/iot-core/connect-your-device/mtp))

 

Another task I had to setup this week was trying to figure out how to fabricate parts in the techspark space as well as collaborate with Joy in order to interface the parts I am fabricating with the stand she is working on. I asked around techspark about getting funds or materials for Capstone projects but I think I need to ask the professors and TA’s in more detail next week. Furthermore, the interfacing will probably be held until next week as well.

 

A final task that I planned on starting concretely for this week was getting the testing rigs (mainly the star projector) started. I finalized the block diagram and overall plan but I wasn’t able to start the modeling and simulation portion as of yet due to delays from setting up software as well as working on design review presentations. I plan to make up most of this lag next week assuming that our Design Review presentation is rugged enough to make the Design review report easier to finalize. If this is not the case I might have to put in some time towards the end of next week to try to get this done before spring break.

For risks I don’t foresee any more structural/implementation problems that could arise (other than the ones discussed last week). The only new risks are operational and managerial ones in the forms of delay and lack of sync that should get handled by more rigorous attention to checkpoints set by our schedule.

 

For next week the plan is to flesh out the testing rig in solidworks and finally get things on the compensator side fabricated so that I can start integration with other team members. With the RPI setup and working properly that can go into the backburner for next week in the interest of finalizing fabrication.

 

Team Status Update for 22 Feb. 2020

Parts that might be falling behind

The selection of an appropriate gyroscope sensor was originally scheduled for this week, but complications with circuit simulation for the motor controller circuit have prevented us from working on it. Fortunately, we are still in compliance with the Gantt chart schedule for this (circuit design isn’t really required for the gyroscope sensor), and we still have a few weeks set out for board layout.

Risk mitigation

There is a risk that our fabrication schedule will fall behind due to some delays and our being unfamiliar with the logistics of doing fab work through capstone. Some solutions to get around queue times/techspark issues would be to go through different venues and simply acquire the material through capstone but the machines through outside organizations like Roboclub.

As far as delays accrued over other portions of the project the only real solution is to revise our schedule after the main set of fabrication is done to more easily catch up on unforeseen complexity.

Additionally, there is a chance that the motor controller PCB will experience catastrophic failure when turned on. We’ve been calculating expected power dissipation/maximum voltages using SPICE simulation for the components to ensure that the components we selected will never exceed their maximum ratings, but simulations don’t truly account for component variations. Furthermore, we’ve only been performing circuit simulations — EM simulation is out of the project scope, so the PCB layout may very well degrade the circuit performance to the point that components are stressed past their ratings.

Furthermore, the propagation delays for the motor controller pins could be significantly higher than simulated, producing complications for the programming phase of this project. There isn’t much that can be done about this — data on the digital components of the motor controller circuit is extremely limited and the models we do have appear to be simplistic.

Schedule Adjustments

Right now most of our focus is going towards finalizing fabrication but that was accounted for in the original schedule with several weeks of slack to compensate.

Progress Photos

Here’s a 3D render of the 3V SMPS standard cell that was laid out this week for powering our project’s stepper motors. This module can be easily integrated into the final layout for the motor controllers by copy-pasting it in. The 3V output is accessible on 3 sides of the cell, making it more flexible to use during the place and route process.

Kenny Ramos’s Status Update 02.15.20

For this week I began work on the rotational velocity step down for the Polar rotation compensator. In order to properly compensate for the rate of rotation observed in the night sky the final rate of rotation for the mount must be an average of (1 Rev/Sidereal Day) or about (360 deg/86,164s). The highest resolution stepper motor we found within our range managed (400 steps/rev) so it was necessary to step it down by at least a ratio of (86,164/400 =  215.41 ~ 215.5 = 531:2) to achieve proper output rate given a stepper motor rate of 1 step per second.

We decided to attempt a step down of 640 at a stepper motor rate of 3 steps per second. This would produce a ~1% error in the rotational displacement of the equatorial mount from the target which is more than acceptable and can even be corrected for once the error accumulates to ⅓ of the effective step output (that is to say the distance that the final portion of the mount is moved for every step of the motor). This correction would be done by occasionally adding one leap step when this ⅓ metric is reached.

We decided to achieve this gear ratio by combining a 32:1 compound gear train with a 20:1 aluminium (or stainless steel) worm gear (bought from vendor) to both accommodate for the high ratio and a 90 degree torque transfer.

The compound gear design was made in Solidworks with a series of 4:1 and 2:1 gear ratios and motion simulations were run with ABS material properties to test resilience of a possibly 3d printed gearbox.

Some potential risks that remain with this design are inadequate gear shaft strength or inadequate gear meshing. Contingency plans for this part include:

      • ordering gearboxes from only vendors
        • although the high step down means that these are much rarer to attain and could prove more expensive and specialized for purposes that are not needed (such a much rotation rates or input torques)
    • Using a smaller step down ratio to turn a standard barn door mount as suggested by Joy. The solution would involve socket that would be turned with lower resolution than the (360 deg /86164 s) used for standard EQ mounts coupled with a device known as a barn door tracker that would provide much more fine tuned aiming. This would limit single capture length to around 10-20 minutes but would prove a lot more easily implementable.

 

My work for the week prior included implementing a library that would work backwards from telescope positioning to obtain the user’s equivalent coordinates. This is done by working backwards from known star positions and telescope displacement.

 

I also wanted to address the “Skychart” laser array for testing image drift and compensation. I was supposed to begin the process last week but I fell behind schedule and will be making it a priority next week in order to avoid further cascading. The design is simple but there are some design quirks that must be handled, like how to fabricate an appropriate grid for the laser light. Another thing that must be examined is if an average room is an appropriate projection surface for testing or if some hemispherical cover must be made on top of it.