WCTU Update #4

I decided I am going to use the USB LiIon/LiPoly charger – v1.2 charger from adafruit to charge the UR18650Es. Originally, I was planning on connecting 3 UR18650Es in parallel but I will have to devise a way to make sure the batteries do not self-discharge into one another. Connecting 3 cells in parallel will only increase device life, and that is not a priority at this point in time so that problem will be solved later. A priority at this point in time though is devising a way to ensure that the batteries remain within specifications(aka dont explode). To make sure this does not happen I am currently looking at pre-existing protection circuits and the possibility of designing my own. I need to assure
1.) the battery voltage does not drop below the minimum level
2.) the maximum current draw is not exceeded
3.) the battery temperature remains at a reasonable level

Also, I should be ordering the Overo Air Coms soon.

WCTU Update #3

The first sub-system I am designing for WCTU is the battery system. Originally I had planned on using 6Ah Lithium Ion Batteries however there are several problems(as specified here) with these batteries such as underrated protection circuits and small wire size which cause an unwanted high voltage drop. Luckily, the CMU robotics club received a large shipment of UR18650E Lithium Ion Cells that I have access to. These cells although larger than I would have hoped, are easily obtainable and will meet the project’s design specification. My next task is to design a battery charging circuit.

Back at CMU / WCTU Update #2

So I got back to Carnegie Mellon University Sunday afternoon and it dawned on me that my schedule for this semester sure is hectic(61 units)(schedule can be found here ). I hope I still have time for alot of cool projects . Progress on WCTU is coming along slower than I had hoped because for lack of better terms the two students I am “working with” lack motivation. This has left me to implement their sub-systems but hey I guess more experience for me right? Now that I am back on campus focus will shift for refining the (now usable) client code and dummy device to designing and fabricating a real device.

Originally I had planned on making two versions of the device. One powered by an ATMEGA(low cost) and one powered by an Overo Air Com(high cost). Due to time constraints focus will be placed on developing the Overo version because it has wireless built in as opposed to having to interface the ATMEGA with the MRF24WB0MA. Furthermore since the Overo is an embedded linux environment code development and debugging is easier. The ATMEGA version will still be created, just at a later time.

The last thing I will comment on it the protocol used to transmit data. At first, I had hoped to use a UDP connection to connect the client to the device. Since web browsers can only communicate over TCP(unless I used a intermediate TCP to UDP server) UDP was ruled out. Having decided to use TCP, it made sense to then look into the incorporation of websockets. After researching the topic, it turned out websockets would reduce the amount of data the client would have to send to the device as well as reduce latency. Therefore, it was decided a websocket TCP connection would be used however what would be transmitted still remained in question.

Originally I had thought of sending data in fixed positions in the transmitted string but that would not be dynamic. Next, I decided to implement a communication system where a “command string” was placed at the beginning of the main string and its paramaters would follow separated by spaces. This proved to work out well because the messages were easy to construct, understand, and were somewhat dynamic. Messages could be of variable size and based upon whether the client or device was sending the message, what the message type was, and the number of parameters different actions would be performed. This system is still not fully dynamic though because the client and device have a preprogrammed contract built into them where the client assumes the device has one input and output channel as well as what voltage, frequency, etc it can read or output. Currently, I am working on an initialization system where the device will communicate to the client upon connection what channels it has, their parameter limits, etc.

Also, originally the only two values the client could request was battery voltage and output waveform settings. The input waveform and output waveform were sent to the client by default. This design was inefficient because if the client was not displaying the waveforms, the data would still be sent. The new API is highly simple and flexible. Once the client connects to the device it receives a battery voltage and output waveform settings message. Whenever any of these two values are changed, the device automatically sends out the updated values to all connected clients. There are two methods void setInputWaveform(boolean value) and void setOutputWaveform(boolean value) which each set whether or not the device will send data to that particular client. void SetOutputWaveform(string type,int voltage,int frequency,int offset,int pwm) unlike the previous two methods is device specific not client specific. When a client changes the output waveform, that change applies to all clients.

The beauty of the API is in the callback function though. The user upon connecting to the device through DeviceManager sets a callback function with the parameters (int deviceId,string type,string[] params) that is called whenever the client receives a message from any device. This method allows the user/designer to customize the API to perform specific actions upon receiving certain messages.

Here is the github repository but be warned the code is largely in flux right now and if you pull the repository the documentation may be out of date and/or the code may be broken. Also, the c_interface is currently halted as the python_interface is easier to prototype with(python interface is the one you want to check out).

WCTU – Update #1

I have not been posting about WCTU(Wirelessly Controlled Testing Unit) as I have been making progress on it because the project has alot of (confusing) sub-tasks being worked on at once. I hope to have a full schematic laid out by the end of winter break for v1.0(ATMEGA powered version). The c-interface I also hope to have done at that time.
The sub-task of focus recently has been developing the html interface. This interface will hopefully communicate directly to the device without the dependency of a server. Originally, I planned on only having the device communicate with the computer via UDP however since HTML5 Websockets require a TCP connection I will need to implement that on the device as well. In hindsight, TCP is probably worth implementing so that when the user wants to set the voltage to 8V it isn’t accidentally set to 30V. Since the interface requires html5 sockets it will only work in Chrome at this point in time.
Pictures of the html interface can be found below. As shown, the interface has 3 main components(controls, oscilloscope, console). The controls are used to control the device while the oscilloscope will display all connected device’s readings. The oscilloscope uses a library called Smoothie Charts to plot the points. The console is used to output general, warning, error, and alert messages(each message type is color coded).

I plan on pushing this sub-project’s code to Github in the next few days. I still need to add the buttons used for controlling the device as well as implementing the method for plotting actual data from the device(right now it just plots dummy data but I do have a dummy server set up using Tornado).

I am Back

It has been pretty obvious I have not updated this website in a while. However that means I have been busy with alot of cool projects . Below are a few projects I have been working on.

1.) Singularity – a Facebook app that I have been working on with Ryan Lin. More details will be disclosed as we get closer to releasing an alpha testing stage.

2.) WCTU(Wireless Controlled Testing Unit) – A wirelessly controlled oscilloscope / power supply that is designed to be portable and modular. The project currently has $1170 in funding($500 from CMU Robotics Club and $670 from a CMU SURG). The project will be published in May and will be an open source project.

3.) Vision Sensor for the Blind – Basically this is all I can say. It is my paid research position at CMU.

4.) ARDrone – The beginning of the semester I was more involved with this project however hopefully in the spring the project will gain speed again. Basically Parrot made a drone and we added facial tracking/swarm intelligence features.

Also, this summer(summer of 2012) I will be interning at Qualcomm as a software engineer in San Diego. I am so thrilled I will be living in San Diego for 3 months. More details are soon to come(if I survive finals week(aka this week)).

The Cogito Project v2.0 Firmware – Done

The firmware for The Cogito Project v2.0 has been done for about a week now. It works fine on my Mac however when plugging the board into the Linux machine on which The Cogito Project server code will run, the board is not detected. I am currently researching what may be the cause of this as it is to my belief the board has characteristics that will allow both the D+ and D- to rise above 2.8V and below 0.3V when necessary. The idea of making this project purely microcontroller based has also crossed my mind which would eliminate the need for a laptop however I first want to try to get this usb format working.

OpenCV VideoCapture:set is not a cooperative function

Last night I upgraded to OpenCV 2.3 through a source build in hopes of getting the VideoCapture::set function to work. Many forum threads stated that this function does not change the camera resolution like it is supposed to. Supposedly it was fixed by the last version(2.3) but my camera may just not support the resolution I am requesting (320×240), so I am not entirely sure what the problem is. Nonetheless, it is not critical that this function works but it would be convenient.

Currently, I am modifying the “OnlineFaceRec” source code from this page to work with the c++ OpenCV API and for use in The Cogito Project.

Found a Way to Send Emails through C++

Originally I planned on using a c++ API to send an email with an attachment of a frame from the camera to my phone when a person other than myself was detected by OpenCV during “watch hours”. It turns out libcurl had no built in support for attachments and since the focus of this project is to create a security system and not an email client, I looked for an alternative solution. Next, I found jwSMTP which has support for attachments but the authentication method is not used by gmail and thus I ruled out this library also. Lastly, I found a perl program sendEmail that works with gmail’s smtp servers and can handle attachments. It will be incorporated into the c++ program via a simple system call.

Back To The Cogito Project(v3.0)

Development on my projects has halted for some time as I have been busy studying areas of OpenCV, facial recognition, and Op-Amps. Also, it might have to do with the fact that it is summer . I just created a page for the LW Bot which I will update as I create schematics and finish v1.0 of the code. Adding the gyro and accelerometer to the robot is a difficult task because I do not have PWM cables that simply mount on the slots and thus I must run a large bundle of wires to the breadboard. The wires easily fall out so I will have to solder them. Also, I am still not sure how I would like to go about controlling the robot although I do know I would like to interface it to v3.0 of the Cogito Project which I am currently developing. In this version V-USB will be used for communication between the atmega and computer. Currently I am developing a sub-system for this project that will send a text message of a face that is not my own if it is detected in my room during “secure hours”. Code for this system will be posted before LW’s schematics probably, because The Cogito Project is on the front burner at this point in time. I would like to finish v3.0 before I go to college.

ARLP v2.0 – May Launch Video Posted

After finally obtaining the recordings, from my friend, of ARLP’s first time in action I threw together a quick video showing the launches. I cut out any video of after the launch for two reasons. First, since it is a high school club I do not want to have to deal with media release forms for minors and all that legal stuff. Secondly, the rockets ultimately crashed and burned. The first broke off a fin but was re-launchable while the second drove itself into the ground and the third exploded as it traveled horizontally into the woods behind the launch pad. ARLP did what is was suppose to do while the rockets were rather … well embarrassing.