Log

Entries are inverted! So, most recent entries are at the top!

DRIVE https://drive.google.com/drive/folders/0B7ipyEBLqXmCQnJXZVdQbkV2YWc?usp=sharing

TODO https://docs.google.com/document/d/1brgUMp4X6FrquF0WJPQT2OxwdAMstguSBW7mL7iq-yQ/edit?usp=sharing

Week 5 Spring 2018

EECS Progress:

Got arduino to read/write to servos, motors with encoders
Got nodejs and express to serve our website. ws to transmit data.

Week 4 Spring 2018

Met 3 times:

Mechanical meeting: April 26 2018

CAD Training and brainstormed the Tread design

Networking meeting: April 26 2018

Got websockets to work
Implementing websockets to send JSON of dx dy from joysticks
Watching videos on websockets
Using ffmpeg to send webcam data!

Microcontroller meeting: April 29 2018

Got arduino to control servos and read from distance sensor
Tested L298N chip.
Buying Anderson Powerpole things.

Week 3 Spring 2018

Billy updated the dragonboard and is trying out a couple new Webcam streaming packages, like motion!
Thomas found the JSON object to transfer from the Joystick controls
Godwin and Yihan discovered some things to test with the motor driver and PWM controls.

March 10, 2018

Mark pointed out that our self-balancing tread design would need a couple more sensors on the front and the back of the chassis in order for the robot to detect stairs that go downward. This is quite a challenge to implement into the current design, so we are taking a break from the current self-balancing approach and thinking of possible new solutions.

February 24, 2018

Redesigned chassis after building tread formations. The orange will be 3D printed, and the blue slabs are acrylic laser cut. We decided the 3D print the sides + L brackets so we have fewer moving parts (otherwise, we would have slabs with many L brackets to hold things together.

January 25, 2018

Continued CAD for the chassis and got to chat with Jesse, the student org's previous president! Jesse gave great tips on where to get help, like PIB, ECE Makerspace, and reaching out to him.

Still trying to debug PID self-balancing. Tetrix parts should be arriving by next meeting, so hopefully we can get the CAD worked out with those parts available to us for measurement. We have a webcam now, so we'll try to play with that soon too :D

CAD sketch of chassis in OnShape

January 18 + 20, 2018

Started the CAD for the chassis! We are also doing layout for the electronics. Dissecting the javascript joystick application we found so we can apply it to our website. Constructed the self-balancing robot prototype for testing with the Arduino code. Something seems buggy with the wiring or code... Our MPU 6050 is also tilted way too much. Continued CAD and designing the dimensions/connections.

Drawings for iteration 3 chassis design

January 11, 2018

Over the break, we cleaned up the Javascript (server and browser) to have all its constants in one file. Before, it was difficult to keep track of which variables enumerated to what and which signals get mapped to which functions on the robot. Now, with all our constants in the browser's script file, both the browser and the server can have access to the constants. We renamed the constants to be more distinguished and understandable. Using the Map data structure also allowed us to directly use the .has() method instead of checking for whether the signal is within bounds. Now, the code properly shuttles the key up and down signals from the browser to the robot. However, the servos are still a bit glitchy and is still not very user friendly.

We also began building a self-balancing robot with the materials we could find. The MPU 6050 chip works with the library <Insert library link> so that's promising. There is also code for self-balancing online <Insert link>.

We are brainstorming the UI designs for the webpage, and a new member, Thomas, will be helping with coding.

Networking of this project looks something like this?

December 9, 2017

Mechanics: We decided to use Tetrix bc they have treads + a pretty good motor.

EECS: Started experimenting with MPU 6050 chip. Will look into how to hook up the Tetrix motor encoder to Arduino. Will continue research over winter break.

Networking: Decided to clean up networking code with exporting enums. ran into some trouble exporting and importing between client-side and server-side JS. Still working on this.

November 18, 2017

Today we realized that we could connect the DragonBoard directly to the ResNet wifi in the residential areas, eliminating the need for a router. Upon testing our old design, we realized that both the wheels and the robot chassis were too small for stair climbing; as our visiting mechanical engineer so eloquently put it: "It's like a puppy trying to climb stairs."

The good news was that we finalized the design of the robot to be a self-balancing robot with treads. The robot design may be found below (ignore the blue wheel). The robot will have two modes: moving and stair-climbing. Each side of the robot will have two sets of treads, with one set only rotated into the extended position during the stair climbing mode. The reason for having two sets of treads on each side of the robot was two fold. Firstly, the total side length of the robot needed to be at least 700mm to ensure smooth climbing of stairs. Such a side length would go against our design philosophy of a small, compact home robot. Having the fold-in set of treads allowed for a smaller robot. Secondly, we needed a mechanism for the robot to transfer from its stair climbing mode, where it lays flat on the ground, back to its self-balancing mode.

With the design finalized, we were finally able to put together a shopping list for parts . We plan to finalize the shopping list with the specifications of parts by Thanksgiving and begin work on the robot once the parts arrive.

November 11, 2017

Today, we tried looking for ethernet ports to connect our router, but had no luck. Geisel 518 has no ports. Geisel 1041 has 12 ports, but none work with our router. Tell ITS to look at those ports. We also tried some in the PC group study, but none worked (the connection light didn't come up). Will try connecting directly to UCSD-Protected or ask Resnet to make an exception for our router.

As for the design, we scraped the arm idea because we realized that the robot will need arms longer than the robot in order to pull itself up. Instead, we thought about using spoked wheels and having the robot drive up. Another idea was to make passive transforming wheels that can be controlled with a second rotatable spoke (see left whiteboard drawing that has some red in it).

Found motors and encoders to buy.

Whiteboard drawings for Nov 11, 2017. We realized that the arm design won't work bc the arm would need to be longer than the height of the robot (see lower right of the board). Unless we do make the arm that long, we could try doing a self balancing robot that has active transforming wheels (see left wheel design).

November 4, 2017

Today we thought about the new mechanical design for MeTwo because the current iteration seems to have some incapabilities, such as driving smoothly.

Because of some technical limitations with ethernet port availability, we couldn't work on code. We did, however, do a lot of good brainstorming and came up with a viable and fun design to do for our next iteration.

Some ideas we had were:

snake design
Wheg robot with 2 wheels
bouncy curved wheel floppy robots

We decided on:

two-wheel self-balancing robot with servo controlled arms to aid with stair climbing.
- This will provide the stability, simplicity, and agility we desire. It will be a challenge to learn how to make a self-balancing robot, but definitely possible.

October 28, 2017

MeTwo is coming back! We have some new team members, and we made some design decisions during this meeting.

QUESTIONS:
- Scrap old chassis? Start with simpler drive train?
  - Stick with chassis, make adjustments. Hardware upgrades.
- Webcam streaming thru dragonboard or simply attach a smartphone?
  - Continue with OpenCV. OpenCV compile code is ready.
FOCUS IDEAS (choose one):
- Master stair climbing + descending
- Automate wireless charging
- Computer vision and audio to enable "watch-dog" mode
- ~~Room mapping with maze mapping technology~~
- ~~Theft detection with accelerometer~~
- ~~iClicker delivery and pressing abilities~~

Robot code is cleaned up. We are trying to figure out how to use OpenCV to stream webcam data. Amer can bring a GoPro for us to test next meeting. Stair-climbing redesign is in process. Hardware and Robot-driving code algorithm teams are working together. Will need to look into how to read IR sensors.

End of Quarter Wrap-up:

By now, we have our second iteration of the MeTwo robot with a self-made chassis that is designed to be able to climb stairs. This version is run by a Dragonboard, which runs a linux system and can run C++ programs as a client to an eternal server running with nginx and nodejs. A browser can be connected on the local network, which makes requests to the server, which then tells the robot what to do. As seen in the latest video update, there are still mechanical design upgrades and webcam integration in order to make it a practical robot. If we were to continue working on the robot, we would like to focus on making it more robust and more easily connected to the network. This quarter has been an interesting journey, as we have continuously collected interested members to provide this hands-on opportunity to as many as possible. Looking back from what we have started with, it is quite amazing to see how far we've come. Many thanks to the team, for their dedication and enthusiasm for the project. It could not have been more fun without everyone!

06/03/2017

Get Dragonboard driving the robot
- Attempted to install/run the server on the Dragonboard, but npm, n, and nvm to build nodejs are all built for different platforms. The Dragonboard, unfortunately, runs on an architecture that those builders do not build for. Thus, we had to try to compile to source code on the board directly, but then ran out of memory space. To get around this, we searched for whether nginx could be run on MacOS (because that was the other operating system we had), and to our surprise it does! So we built and ran the server on the MacOS system, and built the robot client on the dragonboard. After some tweaking of the servo values, we have a driving robot!

05/22/2017

Talked about how we might charge the robot's battery.
- Wireless charging?
- Made list of people to talk to about power electronics. Looks like ECE doesn't have a power electronics major anymore. :P
Researched into libupm's PCA9685 library. Got the example to compile by linking the right libraries and using g++. (we couldn't figure out how to use the CMake files). Running the example returned a what() error.

$ sudo g++ pca9685.cxx -lupm-pca9685

$ ./a.out

terminate called after throwing an instance of 'std::invalid_argument'

  what():  PCA9685: mraa_i2c_init() failed

Aborted

$ sudo ./a.out

terminate called after throwing an instance of 'std::runtime_error'

  what():  writeByte: mraa_i2c_write_byte_data() failed

Tested the old code that we built last meeting, and it worked! The PWM signal properly showed on the oscilloscope, and we eagerly tried it out on a servo! It works!!! We are not quite sure why it works now, but it could be due to the apt-get upgrade while we were installing libupm.
- Proceeded to set up DC motor driver.
  - Made the mistake of not checking whether the power rails are connected. Took a while to discover that there was no V_M to the motor driver chip.
  - Got the DC Motor changing speed!
  - Got the GPIO pins to output high and low on command!
  - Now we need to write a wrapper class to make talking to the I2C more user friendly and proceed with writing the controls code.

05/14/2017

Went on a Home Depot Field trip! Bought some sheet metal, foam rubber, longer screws, and liquid nails (glue).
- We had the idea of attaching a metal sheet to each wheel's spoke to reduce the fall collision when traversing flat ground.
- Another idea was a slightly shorter than wheel radius ball caster, to support the robot while it rotated the wheel to the next spoke.

Springy metal spokes idea. The metal will tuck under the next spoke and because it is springy will allow stair climbing still.

Compiled MRAA_PWMDriver library, but the initializer for the driver is returning a NULL pointer, which makes it throw an exception: Invalid I2c bus. We checked and found there are three different i2c busses on our board: i2c-0, i2c-1, and i2c-3. Why they skipped 2, we may never know... So the i2cdetect function is able to see them, but maybe the libmraa isn't? So we tried making mraa print the pin number given the name, but the program isn't able to detect its declaration or something?
- Turns out we had to update the library (they just updated the apis and we still had the old code), but even then, the geti2cPinLookup didn't work. So, we decided to do away with that method of debugging and directly looked at the NULL pointer return error. Something kept segfaulting and turns out we needed to run with sudo. Also, changing the header file's extension from .h to .hpp made something work. Well now we know that's a thing.
- Hooray! The code runs! but the servo still does not move. We used an oscilloscope to better view the output of the board. The code only runs properly if we hook it up to the i2c PWM slave chip (trying to test the output of the data pin does not work only connecting the oscilloscope to it). So, we took advantage of the opposite end of the PWM chip (electrically connected to the data, clock, ground, vcc pins) and were able to see the i2c data being transmitted! Sending to a different hardware address doesn't produce the same exciting pattern, so we know the dragonboard and pwm chip are talking. The servo pins seem to output a very tiny signal for a tiny amount of time when we call setPWM(). Is this function supposed to set the continuous duty cycle, or do we have to keep calling it?? Also, when we changed the output to pin 1, pin 1 became weird and distorted on the oscilloscope. Will need to keep testing to have it output steady PWM signals.

Below: Oscilloscope reading i2c output in series with the PWM chip!

05/12/2017

Laser cut the Camera tilting platform
Discovered that we need more screws/standoffs. Will go buy some on Sunday

Here's our bot as of now. Looks pretty cool with custom parts!

05/07/2017

Designed and CADed servo mount for camera tilting
Electronically connected PWM chip to Dragonboard and power source
Researched catching exceptions in web code
Decided to rewrite PWM I2C driver code in C

04/30/2017 - 05/01/2017

Researched how I2C data transmission works.
- Attempted to convert Arduino PWM I2C driver into libmraa compatible form.
Made sure the Raspberry Pi robot still works with Wifi
Began changing the server code into C++ to reduce Javascript overhead
Reviewed CAD model of chassis to make sure we are printing something compatible with our parts.
Hopefully we can drive some motors next meeting!

Snapshot of meeting :D Today we also welcomed two new members!

04/23/2017

Envision Lab didn't seem to open on time, so we skipped soldering for today. Going to try tomorrow.
Buying I2C to PWM chip https://www.amazon.com/dp/B01D9VNXEQ/ref=wl_it_dp_o_pC_nS_ttl?_encoding=UTF8&colid=14JAZNN94RAIW&coliid=I1U9G4P0O9K4A8 to get a stable hardware PWM
Video streaming worked for the first time. It's still a bit laggy but there are a lot of optimization we can try.

Dragonboard + audio mezz is now outputting 5V :D

The multimeter was a bit weird trying to detect the changes between 0 and 5V (works with 0 and 1.8V tho idk why)

04/16/2017

Had an ambitious plan for today, but many things didn't arrive/were closed so we weren't able to get the Dragonboard robot working. Here are some things we did accomplish:

Got most of the driving code converted to use the libsoc/MRAA libraries compatible with 96Boards
- Need to test PWM output
Compiled openCV on the dragonboard (for the webcam)
Got the CAD of the chassis/wheels ready to cut (Envision was closed, maybe bc it's easter??)

03/30/2017

Discussed potential stair-climbing solutions
Planned out chassis + wheels that need to be CADed and cut
- Going with 4 stationary curved pinwheel wheels bc easier to make than transforming wheels
  - New problem: need to stabilize camera
UI will have video feed in center and controls on the sides for mobile. WASD + IK for PC

Stair-climbing ideas, Chassis component layout, UI design

03/28/2017

Robot not tethered to wall anymore (yay for smartphone powerbanks!)
Uses 2 power supplies (9V for motors, powerbank for Pi + motor driver Vcc)
Driving + Client code is in C

It's aliveee!!

03/27/2017

Booted up Raspberry Pi (had to use projector as monitor LOL)
Hooked up Motor Driver (yay!!)
Robot still tethered to wall adapter and driving code is buggy, but WASD commands can now drive robot!
- Client + Driving code is in Python

Setting up Raspberry Pi with projector LOL. And wiring DC motors.

03/12/2017

Electronic + Hardware design.

Going with Transformer wheels, Tilt webcam, Distance + light sensors, Medium-slow speed.

Software (server mostly)

Kaj is our MechE guy. Daniel will look into the electronics!

Google Sites

Report abuse