Some challenges I faced during this project is the problem of how to quantify the audio data in such a way that it is clearly and ascetically visible.
This is a big problem because I found that most songs cause the system to report that it is at 100%. This means that a linear scale would be really boring to look at...
A logarithmic scale would be ideal because of how audio is usually reported, but we want the differential to decrease as we approach the maximum.
What I did in the end was do a logarithmic scale, but instead of trying to find a complex way to reverse it, I just subtracted this value from the max and created a reverse scale this way.
It's a simple solution, but it is very effective; though, I should probably appropriately label everything. :)
Found bug in PolyVertex.IntersectProp where (!a ^ !b) was written as (a ^ b) Fixed Contour and PolyMesh debug offsets in SharpNav.Examples
The chip that I use for ethernet connecticity is the ENC28J60. It is a pretty dumb chip, and does just some basic filtering of incoming packets and helps take care of a few things with ethernet packet construction, so it doesnt have a TCP/IP stack at all.
There is an arduino compatible library, called EtherCard, that handles all of this, but it is very heavy for this application. It does have a really good basic driver for the chip that I can use though. I decided that I will take that and build a TCP stack on top of it. Since the Neptune device can be assumed to always be on a local network, I wont be needing IP, and it will save me a bunch of space and overhead.
I can also use this in my Bootloader (ENCBoot), which will need TCP to self program over the network.
THERE SEEMS TO BE A BIG BUG IN SPECIAL QUERY WHERE THE DAIDS ARE GETTING CLOBBERED
updated to more verbose function names
Added header for ethernet module.Added gitignore to ignore build files
This commit starts the process of using WIX as our installer with windows. The editing of registry and overwiting of previous installations of Dr. Memory needs to be verified.
new nbody initialization
updating ungrouped encounters better
Removed unreviewed and reviewed and all images encounter
Updated the unit tests to follow the same structure.
Separated vsone reranked query
So, it seems that the total current limit from the digital I/O pins on the Arduino is accepted to be 200mA. While that limits the Arduino to directly power 10 LEDs. I've decided to use MOSFETs to limit the current that is being used by the Arduino.
The LEDs still require power, but that power will most likely be supplied by an external power source. The Analog Discovery board offers a 5V, 50mA voltage source, so I'll probably be hooking two of the LEDs (the red one and the yellow one, for consistency sake) to MOSFETs.
Hopefully, you will still be seeing updates throughout the Winter Break. So, while I will not be able to enjoy your physical presence, I hope those of you who are following Observatory during the Winter Break will grace me with your digital presence.
Also implements HTTP Strict Transport on site
remembered why the problem is hard
Requires an account
Everything discussed in this blog entry resides outside the scope of this current project and has not been discussed with other team members, but it represents a direction that can be taken with ballot box. I recently completed work in another class utilizing data-driven documents (d3) and found some of the visualizations to be surprisingly easy to implement in addition to performing well when they were utilized.In my opinion, it would be a really nice feature if the creator of an election would...
The project is almost done for the semester, with the exception of a few bug fixes here and there. One potential future extension Check Up is porting it over to Linux. Because Check Up relies heavily on the .NET framework and WPF, porting Check Up to Linux would require a complete rewrite of portions of the code. This would be a great way to learn more about Linux, however, and is a potential project for next semester or in our free time.
pulling most recent code from repo
Also started playing with pyQt a little bit
With the semester coming to a close, we’ve begun thinking about next semester. We’ve finished implementing the complete foosball table, and now we need to make it permanent. Our RA and RD are both on board, saying they’ll support us when we talk to reslife.
However, due to the Pub Safe and ResLife shenanigans, we are going to wait for a better time to propose our solution. We may decide to put the whole thing in a project enclosure so it looks “safe.”
Things we will do next semester: RFID readers. Manual input panel for Handicapped play, errors that will probably never happen, reset… Website with more interesting stats, Teams. 7 segment pin displays on the table. lasers instead of diffuse light for more precision.
Originally written on Nov 19.
Since last time, we’ve made a lot of progress. We’ve played actual games on our dorm foosball table, and have gotten rid of the bugs which made reading the leaderboard and ticker a nightmare. On Wednesday, we made a poster which displayed these advancements. It was a real success, despite not sleeping the night before.
We’ve changed microcontrollers from the chinese-manufactured-fake-brokenFIDI-arduino-mini to a completely legitimate Arduino Uno. The only bugs we have now - if we had any - are in the code we wrote.
Speaking of hardware, we removed our button placeholders for actual photoresistors. How they detect goals is simple: The photoresistors have light shining from behind them, that reflects back from the bottom of the ball tube(black). When a ball passes through, more light bounces off, which passes a threshold, sending a goal to the python script through pyserial.
For demonstration purposes when we don’t have a foosball table, I’ve configured the script to send out dummy data.
Until Next Time, FoosRPI
Features score vectors are now returned instead of aggregate scalars
Fixed lots of documentation and readability issues
Added template for HTML to test compatibility and usability
Added some profiling code
The PVC frame for Neptune has been made a bunch smaller for maneuverability and I have finally installed and waterproofed the plexiglass window of the main tube. I have also figured out how I will be mounting the motors, and have already installed one.
On the software side, I have written an arduino library for the motor controller, and am in the process of writing a bootloader, which will allow me to program the main microcontroller over ethernet, as opposed to USB or serial port.
We started out on this project last summer with hopes of creating a CMS for a personal project of ours, a non-for-profit owned by one of our own. However, this CMS has taken over as our primary focus right now. It's utility both for our needs and the needs of others is evident to us and will hopefully also soon become evident to users of our system.
One big thing we plan to implement is Angular JS database hooks. With many common templated site systems one major feature is the ability to switch without worry from template to template, however currently we require manual content entry and operate as an editor but not as the software for transitioning. By using Angular to display content on our frontend we can pull from our Mongo setup and allow for content that stays as the templates change. We will need to load hooks from templates that have them and embed hooks for the database in templates that don't, all while making sure the user is able to edit and manage their content with ease.
Thus, we're working on hook merging, embedding, and creation for use with our provided templates and any side loaded templates. While this plan is one of our biggest steps yet, it will add the functionality and diversity of content that we were initially striving for.
We're looking to bringing to users, including professors soon, and hope to be able to keep working on this in the future.
(See you, space cowboy. - Mason)
It has been about a week since our first successful demonstration of Aro Alpha. At the start of the semester we wanted to develop a CMS that would be both simple, beautiful and powerful. In the course of a semester we have made pretty sound progress.
One of the first major milestones was the development of basic artwork and philosophy that describe the user's experience. We wanted a modern UI that contained everything a user would expect in a CMS and would be intuitive to navigate. Much of this effort came in the form of a universal side bar and dynamic toolbar. The sidebar contained just a few basic links to common tasks, such as new page creation and editing, and the top toolbar updated depending on which administrative view was being used. This allowed us to expose additional commands while keeping the UI clean. For example when the editor was opened the sidebar minimized itself and an icon corresponding to uploading the current document appeared in the toolbar.
Moreover we tried to keep the number of icons and options presented to a user minimal at all times while at the same time not burying import links in layers of pointless menus. For example in the editor window the user is only presented with a small toolbar in the top left that indicates they are in the editing mode, and gives options for the user to upload the page, reload it, or open it in a new tab. To actually expose the editing commands a user simply clicks the field he wishes to change and a more complex editor appears ready to accept input. We also implemented simple checks to attempt to load a more complex editor when appropriate, but otherwise present the user with as simple of an experience as possible.
The UI we demoed was clean, modern, and effective, in short exactly what we set out to achieve. While nothing is perfect our work on the front end is a good start.
On the back end things went quite well this semester. Plugin discovery and basic bindings were established and developed enough to be usable. True to our initial goal of modularity we proceeded to use these bindings to develop our admin system and content serving. While much work still has to be done to polish these systems our team was quite pleased with the current state.
Aro is far from complete but we have shown our project has promise and at the very least took a step toward our goal of destroying WordPress. One day, one day soon the world will be free of its terror.
So we demonstrated a working alpha for Aro (check out the screenshots for more info) and I thought it would be a good idea to do a quick overview of different technologies we have used.
The initial project goal was to create an extensible system with an intuitive user experience. This goal had a profound effect on the technologies we chose to leverage. To keep the system dynamic it became evident we would need a database structure that could handle a wide assortment of data.
At the heart of our system is the plugin system and its bindings that allow regulated access to a central database and filesystem. Since it would be impossible to predict the requirements or data types that will be used in future plugins it made sense to choose a database system that could adapt without requiring a massive table dump or routine maintenance. Since we were using Node to drive our CMS MongoDB seemed like a perfect fit.
Basically Mongo has a system of documents organized into collections each associated with a certain database. For SQL users documents are similar to tables, and documents rows except documents are far more flexible. Data in documents can be edited on the fly and it is possible to easily alter the structure of the document making it possible to rename fields, and new fields, etc without the need to rebuild everything from scratch.
In short MongoDB's flexibility keeps Aro on the mark.
This last week I finally got the log in system for android to work with my local server. The next step for me is to finish the logic for sending and pulling tags from the database. This should be a lot easier now since I understand how to send the JSON data to the server using HTTP POST. Overall RCOS has been a wonderful and interesting experience. It was my first semester in RCOS and I really enjoyed my time here. I've learned so much useful knowledge between working on my project and seeing what others were up to. I've already applied a lot of this knowledge to another project I'm starting for my fraternity. Working on this android app has really opened my eyes to mobile development and so I plan on continuing this path. I will continue to work on Tag-it over the winter break and hopefully I'll have a full functioning prototype by the start of next semester.
The bulk of contour generation now lies in Contour, ContourSet should be about storage/cleaning up Fixed bug where backwards contours were never getting deleted/marked as null. Removed raw vertex storage, was only being used to debug draw Modified examples project to remove raw vertex display mode.
Fixed the issue where the word 'Help' was getting cut off in the menu ba...
Fixed words getting cut off
Limited minimum polling interval to .2 seconds