Thursday, December 1, 2016

Update for 12/1

So our school got an interesting offer this week related to FIRST Robotics.  While our school used to have a FIRST team, we took a hiatus after our budget started getting a little tight and all our senior members left.  However, we got an offer to participate in the 2017 competition.  Raising funds to pay the $5,000 entry fee would normally be a little difficult; however, FIRST was willing to waive the fee for us.  It's an unexpected opportunity that I'm really looking into, but it may also mean having to choose between what I've been doing and this.  However, this is almost too good to pass up.

As for what I did this week, I've been helping take inventory with some other engineering students for the parts we have in our engineering supply closet (the place is a mess).  We were also setting up basic FIRST kits in accordance to the 2015 kit of parts (since that was the last competition our school participated in).  In the end, it'll help everyone to clean the closet, including me (regardless of what I decide to do).

Thursday, November 17, 2016

Update for 11/17

For this week, I took a sidetrack from motors and hardware to look more into sonar sensors.  From
Intel Aero Ready to Fly Drone 
the Project Tango devices, the Lenovo Phab 2 Pro seems to have a better sensor, with a camera with a 16 MP resolution; however, I'm not exactly sure if that's just the regular camera or also the depth/motion-tracking sensor.  As for Google's tablet development kit, that has a 4 MP RGB-IR sensor.  There's also another sensor from Intel that's being implemented onto one of their new UAVs, the Aero drone.  While the drone isn't available yet, the camera is already out.  For its price, it's very good, and we might be able to learn something from the applications people find for the camera on the UAV.  In terms of cost efficiency, it would probably be best to go with the Intel sensor or the Microsoft Kinect we already have at our school.

Thursday, November 10, 2016

Update for 11/10

This week, I took a more in-depth look into the motors we had.  Most of the electric scooter motors are variants of the XYD motor manufactured by Currie Technologies and used on Schwinn scooters, with similar RPMs and voltages but different rated currents and outputs.  I was also able to find a performance sheet for one of the motors here, which will help me down the line.  There were also some CIM motors of various sizes.  One type, the AndyMark 9015 motor, has a really high free RPM at 16,000 but a low stall torque at .428 Nm.  We could gear this down a lot to get to a desirable speed, but there are other options.
One of the Window Motors

In addition, we also had a large amount of window motors, which have really slow RPMs.  I didn't think they'd be useful, but I was curious and did some research on one of the motors manufactured by Denso.  Apparently, they've been used multiple times in FIRST competitions, and there's quite a bit of documentation for it.  Here's a copy of one of the data sheets I've found.  Two important points for me are the RPMs and stall torque. While it has a slow RPM, it has a really high stall torque, and with appropriate gearing, we could get reasonable speeds.  Considering that it might be better to have a slow go-kart to give the sensors more time to collect data and the go-kart more time to react to obstacles, these might not be such a bad idea.  I'll need to spend more time analyzing the spec sheets of each to figure out what might be best, though it's certain we're using two motors.

Aside from motor research, I also spent some time looking into Google's Project Tango, a platform used for augmented reality and 3D mapping (among other applications).   While Marina and I were doing some research into possible depth sensors earlier in the year, I came across Tango but dismissed it (perhaps too quickly) since it was still relatively new.  However, very recently, the first Tango-enabled phone was released.  It has a good camera, and the technology inside could be applied here to our purposes.

Thursday, November 3, 2016

Update for 11/03

Motor on Kart Kit - it's hard to find the
specs of other motors when their labels are
scratched much more than this or nonexistent.
This week, I decided to focus more on the hardware for a full-size go-kart.  Fortunately for us, we'll be able to salvage most of the structural and drive components from last year.  For example, in addition to the materials used on the kart kit, our school has spare 12V batteries, 80/20 aluminum frame, VEX VersaFrame, and sets of tires ranging from 4" to 8" from last year.  Moreover, there's still a few motors and motor controllers around.  I decided to look into the motors to see what specifications they had.  Though I couldn't find information on some, most came from Razor scooters and were of similar design to this one, with a voltage of 24V, an output ranging from 250-400W, and a RPM of 2600-2850.  However, since we're planning on using two, we need to be certain of the RPM so that we don't have two wheels moving at different speeds and will probably need to test some (or look some more; we could have overlooked a few).  I didn't find any fuses or kill switches we could use, and there are other safety features we would need to put on to be eligible for A-PRS, like bumpers.

Though we haven't fully decided on parts, I decided to run a few rough calculations given some of the parts we were planning on using.  Given a motor with an RPM of 2600, 6" diameter tires, and a 5:1 gear ratio, we're probably looking at a speed of a bit more than 9 mph.  It's a little slow, but since it'll be autonomous, it might not be so bad.  If we were to use motors with an RPM of 2850 and a gear ratio of 3:1, we'd be looking at a speed closer to 17 mph.  If we were only using one motor, this would probably stall, but since we're looking at two, it'll probably be more feasible.

VEX Room after cleaning
Furthermore, later in the week, we received some servos as part of a VEX shipment.  I promptly mounted one on and began to alter the code to accommodate a different motor.  However, I didn't have too much time with it.  I was able to set its rotation with button presses, but I didn't get the chance to see if I could use a joystick to control it or incorporate it into any autonomous code.

On another note, since the VEX room where our prototype is was getting messy with so many working in there (besides us, about six others), we spent some time cleaning up the room and organizing all the tools and parts.  It's important to keep a tidy work-space in order to stay efficient and minimize delays. Besides, the room is bound for an official inspection at some point, and it wouldn't have looked good in its former state.

Thursday, October 27, 2016

Update for 10/27

The Kart Kit's Underside
The code for the prototype is coming along well; I've been able to program it so that it can utilize its sonar module to automatically stop in front of an object.  In theory, it should also be able to use the sonar module and gyroscope to turn around an object and keep moving.  However, since we still don't have a servo motor, I haven't been able to fully test it.  For it to work, I need a way to lock the motor controlling the swerve drive kit at a certain rotation, and I haven't figured out an alternative way to solve this problem.  At this point though, we'll probably start focusing more on designing a full-scale kart; if we need to, we could always go back to the prototype to add parts/code and test functionality.

As for the full-scale go-kart, we're likely going to go ahead and either use or create a copy of the existing unused one at the school and expand on the basic design.  It was built last year by two seniors as a concept for a kart kit for the Power Racing Series and was intended to be a bare bones design that could promote discussion about improvement among students.  They posted their assembly files and a parts list online on the Power Racing Series wiki here if you'd like to read more about it.  Though I haven't put deep thought into structural components we may add, just from looking at it, I know we'll need to add foot protection, bumpers, a kill switch, and fuses (I think) to comply with PRS and A+PRS rules.  I'd also like to add an additional motor, larger wheels (I used 4" wheels last year in a go-kart, and it had almost no ground clearance), and additional driver p

Thursday, October 20, 2016

Update for 10/20

Part of the Code
For this week, I added in a basic program that toggles forwards autonomous movement, slowing to a stop in this mode if it detects an object in front of it.  From here, I started to add code that should allow the prototype to autonomously drive around an obstacle.  In addition, I put in code for the LCD to allow it to display the battery voltage when a button is pressed.   

However, when we attempted to use the autonomous code, we encountered two problems.  One of the problems was just related to the code structure, which Marina mostly fixed.  The other problem relates to specifically what data the accelerometer and gyroscope receives.  In the previous week, we never truly paid attention to the values that the accelerometer and gyroscope gave us and just focused on if it worked and gave us feedback.  However, when I took a more in-depth look, I noticed that some of the values were really strange, especially compared to data received on the VEX robot from last year.  I did some research, and as it turns out, sensors in EasyC use different units/precision (for example, degrees vs. tenths of a degree) compared to ROBOTC ( at least by default).  The ROBOTC wiki clarified this for me, and I adjusted the code accordingly.

For next week, I'll continue to update the code to allow for more autonomous capability.  As for the actual go-kart, we may end up modifying an existing go-kart left here last year.  It's no longer being used by anyone, and while it's very basic, it'd be simple to expand upon it structurally and electronically.

Thursday, October 13, 2016

Update for 10/13

This week, I decided to go ahead and switch to using ROBOTC to program the prototype.  It took a bit of time to figure out the interface, but I was able to quickly whip up some sample code.  This time, I had no problems uploading code to the prototype, not encountering any problems with updating the cortex's firmware or establishing a connection.  It worked much better than the stock firmware updater and EasyC, and because this allows us to get back on track, we should be able to move past the scale prototype stage around the end of October.
Interface for Assigning Sensors to Ports

In terms of actually testing the robot, I found a few problems in wiring the modules since ROBOTC operates slightly differently than EasyC; however, it didn't take long to fix.  I was able to receive input from all of the sensors and display it on the LCD.  However, in terms of utilizing it to navigate obstacles, I haven't finished coding it.  Additionally, the motor used to turn the robot doesn't have the strength to turn the wheels effectively, either due to the way it's mounted or its gear strength (1:1 with the wheels).  Replacing the motor with a servo might also help, but at this point it doesn't seem too important.

For next week, I need to strengthen the motor used for turning and write additional code to allow the robot to navigate obstacles.