Nick Kasi’s Work Log

Nick Kasi’s Work Log

  • Post author:
  • Post last modified:April 18, 2024
  • Reading time:88 mins read
  • Post category:Work Logs

Tuesday, September 19, 2023

We met with Nick Sandahl and Adam Sandahl, two members of OSHE that worked on Growbot the previous semester (Spring 2023). Though they are working on new projects now, they agreed to help us understand some existing parts of the Growbot. After trying to puzzle out a breadboard and old versions of the code, we ultimately got the robot to power on and spin the front wheels while Nasi held up the back of the robot (it is currently missing back wheels so we had to improvise). We were using a joystick with very inconsistent responses for moving forward, backward, and turning.

We decided to purchase certain components. We need a new FlySky controller as the one from previous semesters is broken, and the joystick really isn’t cutting it. In addition, we need swivel wheels for the back of the robot, since it is using front wheel drive and thus the back does not need motors. We also need foam for the water cover and a new axle.

The rest of this log will contain notes that we took while trying to get the Growbot moving again.

Motor Controller:

  • 4 Cable input (Red, Orange, Yellow, Green)
    • These cables are connected on the side of the motor controller that I will call the “front.” It is facing the direction of the ultrasonic sensor at the front of the robot. Two cables are controlling Motor A, two are controlling Motor B.
    • When all 4 lines are high or all lines are low, the motors will stop.
    • The 2 cables on each side of the 4 cable input are PWM. The PWM controls the speed that the motors will run at. One cable controls Motor A, the other controls Motor B.
    • You can see in the code which Arduino pins each wire connects to.
    • Note: Make a schematic so you don’t have to look at the code every time!
  • On the motor controller, there are yellow wires coming out of 3 sides. The front two are going to the battery. The ones on the side go to different sides of the motor.
    • To re-iterate, each pair of wires on the right and left side of the board connects to one motor (motor A = left, motor B = right) (Black tape indicates ground.)
    • The front of the controller has an extra 5V port to power the Arduino. It is next to the 12V battery inputs.
  • RISK: IF YOU ARE CHANGING THE BATTERY FROM 12V TO HIGHER
    • (The 3 “input” pins on the front side of the board, if you are looking at it from the front: the left is high, middle is ground, right is the 5V)
    • Remove the black jumper pin right behind the terminals (which will remove the 5V line)
    • If you don’t remove the jumper pin and make the input higher than 12V, then the board gets fried! Don’t do that!
  • Note: Take a photo of the motor controller and label the different ports! But please make it look nicer than this, I used MS paint.

Code:

  • There are several sections of code commented out, usually involving something called “iBus.” This is code configuring the FlySky controller. Since we don’t currently have a FlySky controller, the code is using a single joystick. When you convert back to using FlySky, comment out the joystick code and un-comment out the FlySky code.
  • We were viewing the code in the Arduino IDE (Nightly) which can be found on the arduino website. The code itself was found in the google drive under the “Arduino” folder. The code has since been modified, but this was the the base.
    • Note: Put the new version of the code in the google drive!
  • When verifying the code for the first time, a common error you will face is that certain libraries cannot be found in the code.
    • Click the “library” button on the left side of the screen (see image below), and look up the library that is causing issues. Then, hit “install.” If it still doesn’t work… We just installed a bunch of similar-sounding libraries until it worked eventually.
An image showing the location of the library button in the Arduino IDE.
  • In this post made by the previous Growbot team, there is a table at the bottom of the page showing links to various tools. If you are still having issues finding libraries for the ultrasonic sensor or the humidity sensor, start looking there.

Possible future changes that we discussed but aren’t planning to implement any time soon:

  • Add another electronics board on the bottom of the robot for a more organized way to connect to sensors/motors. Currently there is quite a distance from the top electronics board down to where the components are, and it can get messy or tangled/disconnected.
  • Power the arduino seperately from the motor controller using a DC to DC buck converter. The arduino MUST have 5V or less to avoid damaging it, so we need to convert from the 12V battery.

That’s all for September 19th!

Thursday, September 28, 2022

This week, my grand mission was to get the FlySky Controller working. We ordered a new controller, but Dr. Shane also allowed us to use the controller of a decomissioned project: The quadcopter. However, we still needed a receiver, so for testing purposes I used the receiver of the new controller. (It ultimately doesn’t matter which receiver and which controller is used, they can be paired.)

Also, today I emptied out the Growbot cabinet to inspect everything inside and try to find the old receiver. I could not find a receiver, but there are many unused parts in the cabinet that might be able to be removed to clear up some space. I also put all loose cables in a plastic bag, so it is easier to find something to use when needed.

I used this website as a starting point. To bind the receiver and the controller, I used this video.

  • Connecting the receiver to the Growbot

The receiver looks like this (See above). In the background of the image, you can also see the quadcopter FlySky controller that I was using. In order to hook it up, 1 pin needs to be connected to the Arduino MEGA, and 2 pins need to be connected to some kind of power source. In this case, I was connecting it to the 5V and Ground lines on the breadboard.

In the code, you will find the location to plug the receiver into the Arduino MEGA. This is our “iBus” and it is Pin 19 in this image.

  • Pairing the Receiver with the FlySky controller

Now, when you turn on the robot, the receiver will have a flashing red LED. In order to pair it with the controller, you can connect the binding key to the rightmost 3 pins on the receiver (see below).

When the FlySky controller is off but the receiver is on, press and hold the binding button on the bottom left of the FlySky controller. While holding this down, turn on the controller. It will go into “binding mode” and find the receiver.

  • Issues

The FlySky controller would play display that the receiver had no power (RX and an empty battery symbol on the screen). I charged the Growbot Battery but this problem persists. It is possible there is a certain voltage level that the controller expects. If there is a way to lower the voltage threshold, it may remove this issue. Until this issue is solved, it will be difficult to test controls. However, the receiver and controller both turn on and recogize each other.

Another issue is the organization of the breadboard. I am struggling to find a way to plug in the receiver that does not cause visibility issues and further confusion: We are going to have to do a lot of wire management.

  • Future plans

We have been working on waterproofing the robot by cutting new covers and ordering a foam seal to ensure no water can enter the electronics enclosure. In addition, we have been working on our presentation for the Critical Design review. We are reconsidering using caster wheels for the back wheels of our robot due to traction issues. Ultimately we hope to get the robot moving using the controllers and let it stand on its own 4 wheels (instead of the 2 it is currently using).

Friday, October 6

This week there was more work on the FlySky Controllers, the waterproof cover, and some repairs.

  • Issue with the FlySky alarm

Last week, it was noticed that the FlySky controller would successfully bind to the receiver, but it would constantly sound a warning that the receiver had no battery. Despite it being difficult to find people with similar issues online, we found a way to prevent this from happening. First, operating the menu on the controller was a bit difficult, so this website clarified that holding down the “cancel” button would confirm a selection. Then, in the settings the threshold at which a low power alarm would sound would have to be reduced. The low power may be an issue in the future, but it is difficult to troubleshoot when an alarm is constantly going off. The steps are as follows:

  1. Hit “cancel” several times to return to the main screen
  2. Long press the OK button to open the menu
  3. System>RXsetup>RXbattery
  4. On both the external and internal sensors, set “Low” and “Alarm” as low as possible (0 or 0.1)
  5. Long press cancel to confirm

Afterwards, we ran the new code on the Arduino to see if the robot had any response to the controller. The results showed that the robot would run backwards until the FlySky controller was detected, at which point it would stop. When the right joystick was moved, the motors would turn extremely slowly, almost imperceptibly. However, it was a sign that the robot was indeed receiving signal from the FlySky.

(Note: Adjust “default” cases so the robot does not continuously run. Find out if the slow motor response is due to battery issues or code issues.)

A few other issues were discovered during testing. The robot seemed to run out of battery, so it was recharged, but after re-attaching the battery the robot would refuse to turn on. Nasi discovered that the power switch had been disconnected from its wires, and fixed it with some soldering. Eric worked on the waterproof cover and securing it to the frame.

  • Future plans

For next week, we will be presenting our Critical Design review. In the future, we want to get the caster wheels on the robot and the FlySky more reliably controlling the driving. In addition, we need a more permanent way to secure the receiver.

Friday, October 13, 2023

This week, we presented our Critical Design Review. We received a lot of important feedback on our project, so we re-assessed our plans.

Planning

Here are some possible modifications to our plans for the rest of the semester:

The objective of the project for Fall 2023 are the following:

  • The entire device will have design files that originated entirely from free and open source software.
  • The electronics will be secured – Achieve a robust packaging of electronics
    • The electronics should not move or disconnect while the robot is in motion.
    • The Arduino Mega and the Breadboard are currently secured with tape, the motor controller has a 3d-printed housing, and the battery is connected with velcro.
    • The wooden electronics housing can be converted to plastic (PVC or ABS board), the breadboard and arduino will be secured with screws and spacers
  • The electronics will be organized – The electronics packaging will be optimized for a modularity and accessibility
  • Create new wiring diagram in KiCad
    • Update with all modifications to the electrical circuit.
      • FlySky receiver
      • 5V Power line from Motor Controller
      • Remove components that are no longer on the robot
  • Replace damaged gears
    • Evaluate if there is a stronger material available to print, else print multiple so that replacement gears are available
  • The robot can be powered on safely
    • Add a circuit breaker/fuse on Hot side of battery
    • Add a circuit breaker/fuse on 5V line to Arduino mega
      • Arduino mega: 100mA
      • Check power consumption of Motors (Make sure Multimeter is measuring using the right pins OR use the lab clamp thingy from Lab 5, b/c multimeters can’t always measure high current)
    • Measure current on 12V battery when motors are not running
    • Measure current when motors are running (difference is motor)
    • Double total amperage for fuse value
  • Improve maneuverability of the robot
    • Attach swivel casters for back wheels
  • The electronics enclosure has a water resistant cover
    • Extra sealing with gasket

Code

In addition to this planning, troubleshooting for the code continued.

When the flysky controller is off:

  • If the robot turns on when Auto mode is DISABLED, nothing happens
  • If the robot turn on when auto mode is ENABLED, it will go forward (even if the auto switch is subsequently turned off)

The code was modified to test if Auto mode switch can affect robot operation. A second “else” (image below) was added to disable motors when the auto switch is off. It would stop the motors, but they would make a jerking, clicking sound.

Once it detects the flysky controller, it will no longer run normally, and usually have either “jerky” motion or no motion at all (when right stick is moved).

  • Potential solution: Modify motor speed within the code instead of motor direction. (Image below shows FlySky code affecting Motor direction.)

Next week, we will discuss plans regarding removing the breadboard and attaching wheels, as well as learning more KiCad to update the schematic.

Wednesday, October 18, 2023

The code has been sucessfully troubleshot! Trouble…shooted? In any case, the past few days many more issues have arisen, but a lot of helpful information was gained.

Physical issues

  • The motors appear to struggle moving, and it is not code-related this time. Even in auto mode where they would run continuously, the left motor is not making any sound or movements, and the right motor is making faint sound but not moving.
  • We will have to detach the motors and test them individually, as well as checking the wires for any issues. If the problem is the motors themselves, we will need replacements.

CAD

  • The CAD for the motor mount is located in the Shared Growbot drive under Growbot>CAD>Fall 22>wheelMount_2.4.FCStd
  • Eric is working on re-printing the cracked front housing and adapting it for our back wheels.

Code

  • After consulting with Adam Sandhal, he suggested that we use the Serial Monitor to see if the issue is signal strenth, code, or a physical problem.
  • To use the serial monitor, you can open it in Tools>Serial monitor in Arduino IDE and setting the baud to 9600.
  • In addition, the baud in the code must be 9600 (Where it is written: Serial.begin(9600)).
  • If this is not the case, the monitor will output a bunch of junk. (See below).
  • Once the baud is successfully set, Serial.print(“Whatever you want to print”) can be inserted into the code where needed.
  • I added serial print for all situations of Auto mode and RC mode. I quickly found that turning the right knob all the way counter-clockwise turns OFF RCCh6, and turning it all the way clockwise turns ON RCCh6. So, when the knob is around 11PM, Auto mode will be enabled, when the knob is around 8PM, RC mode will be enabled.
  • The serial monitor pretty clearly shows that the arduino can sucessfully detect when the right stick of the FlySky controller is giving inputs. So, the issue is not the signal between the two devices, and the code is setup correctly. (Below, the serial monitor switching from auto mode to RC mode and displaying different motor speeds as the right stick is moved more or less.)

Here is the section of the code that shows serial print when the Y is positive and the X is 0 on the right stick:

  • However, the motors still do not run. Next time we will start working on removing the motors for physical testing.

Timesheet

  • We also created a timesheet for the remaining weeks in order to create goals to work towards and tentative deadlines. The timesheet is not finalized but it is good for keeping track of what everyone will be working on that week.

Returning 6inch casters

  • I will be returning the 6inch Casters next Wednesday.

October 24, 2023

GOOD NEWS! The RC code is now working. UNFORTUNATE NEWS: Many weeks were spent agonizing over a SINGLE LINE OF CODE.

I will first explain the working solution, and then I will explain the previous attempts.

CODE

  • The code for the robot is focusing on one variable: rcCH6. This reads a certain value from the controller. When chCH6 is high, it means the controller is connected and RC mode is active. When rcCH6 is low, it means the controller is not detected, and autonomous mode is active.
  • The robot will only turn the motors when it is ENABLED (disable=0) in the code: this had to be placed once rcCH6 was detected.

All we needed was this disable = 0… I would like to dedicate this success to Adam Sandhal who looked at the code for 2 minutes and immediately figured it out. This is why you ask people for help as soon as possible, folks.

Anyway, today we also spent some time fixing the motor issues from the previous week.

  • First, we removed the motors and Nasi checked the electrical connections by removing the insulation and testing the motors with a Multimeter. He confirmed that the components themselves were fine, and added insulation back to the wires.
  • Eric figured out that some pins on the Arduino were disconnected (the data pins for Motor B on the arduino had come loose from pin 25). After re-connecting this, the motors ran fine in autonomous once again.

Future code issues

  • Now that the robot could reliably switch to RC mode, we faced the issue where it could not switch BACK to auto mode once the controller is disconnected. Maybe this was because rcCH6 would simply stay high once the controller disconnected. We attempted to remedy this in the code by resetting the channel back to low each loop. However, if the receiver is still reading “high” when the controller is disconnected, this value will be updated again, so ultimately this was removed from the code.

Attempt at fixing the switch back to auto mode shown on lines 267-272 on the image above, did not work so it has been removed.

  • Next, we added more Serial Prints to show us in what states rcCH6 would read as high.
    • Turning on the robot with the controller on: 1
      • Then, turning off the controller: 1
    • Turning on the robot with the controller off: 0
      • Subsequently turning on the controller: 1
      • Then, turning off the controller: 1
  • To investigate this further, we took at look at the receiver itself. One of the pins on the receiver is likely sending a high or low signal based on whether it detects rcCH6. We located this by grounding the multimeter (V DC|:) on the motor controller and touching the other terminal to each pin on the receiver (making sure not to bridge the gap between pins). Then, we would turn on and off the controller to see if the voltage would change. We eventually located the pin shown in the image below:

(Note, the middle pin was always 5V.)

  • The following comment was haphazardly written into the code:

 //10/24/2023: If the controller is disconnected, it keeps whatever motor speed was last and will keep going. This means if you get out of range the robot will run away // Possible fix: Attach a pin to the receiver that feeds information about SIGNAL to arduino. When the controller disconnects, the ANALOG signal should go to zero, so // connect one of those pins to Analog in (A1-whatever), and use that to see whether it should be in autonomous mode or not. (2nd from right, top pin) (ranges from .3 to .16) // .16 is when Ch6 is Low (physically) .3 is when Ch is High (physically). When it’s OFF it just stays in whatever it was before.

  • Translation: The voltage on the circled pin is related to the connection of rcCH6, which we are interpreting as the state of controller. When rcCH6 is PHYSICALLY turned down with the knob, it has a 0.16 volts. When rcCH6 is PHYSICALLY turned up with the knob, it was 0.3 volts. Ideally, when the controller is disconnected (losing battery, turning off, moving out of range,) the pin should become low once more. However, we found that if the receiver loses connection with the controller, this pin keeps whatever value it last had.
    • Imagine if you are driving the robot at full speed, and then it moves out of range of the controller. The receiver will keep sending the “full speed” signal it last had even if it has lost connection with the controller and your robot will run away!

ONE LAST ISSUE: RC mode does not properly enable and allow the controller to run the motor if the arduino is not connected to the PC! I suspect that this means the arduino does not receive enough power on its own from the battery, and is using the power supplied from the PC. (I could be entirely wrong, but it’s another issue to think about.)

Ultimately, we fixed the motor issue, tested the motors, got the RC mode working again, and learned a lot about how this receiver works, and it is likely a good idea to re-think the way we are switching between auto mode and RC mode.

November 4, 2023

This week, I tried to familiarize myself with KiCAD in order to work on the wiring diagram. I watched the following video:

KiCAD Quick-Start Tutorial

  • Making a new project/library
  • Creating a symbol with pins and labels
  • Adding components to schematic

Learn KiCad #1 – Make a Schematic

  • Terminals, connectors
  • Common symbols

Just for practice, I created a rough symbol for the Arduino MEGA.

  • Reference: Arduino MEGA Datasheet
  • For now, all of the pins are labelled “Inputs” – this is not true, and the appropriate setting should be configured later.
  • The size is not accurate. I could not find a way to add dimensions (specified in the datasheet) to a drawing. So, this is not to scale, and merely a representation of what pins are avaliable.
  • I am unsure how to cleanly represent the bottom row. Maybe a “long” bottom row instead of doubling up would make sense.
  • Symbols for motors, batteries, and switches are already avaliable.

KiCad window for creating symbols.

For the wiring diagram itself, I will need to make symbols for the following components:

  • Motor controller (L28N)
  • Flysky Receiver (FS – iA6B) – Can’t find a pinout online

For improving the Arduino MEGA symbol:

  • Smaller/more compact
  • No double rows

In the drive, there is a document called “Wiring Diagram V4” which shows Raspberry Pi, Humidity sensor, and other configurations. If adding these back in the future, this WILL be useful.

November 6, 2023

The wiring diagram is looking less empty, but many components are just simple boxes, namely the 12V battery, the motors, and the Auto Mode switch, and no sensors are accounted for. As it stands, all of the pins needed to make the robot driver are drawn. However, the power switch is missing.

  • Re-organized bottom pins on Ardino MEGA
  • Created L298N Motor controller because I didn’t like how the official one looked
  • Created FlySky Receiver
  • Added temporary symbols for battery, Motors A and B, and the auto mode switch (all seen in blue)
  • Need to add power switch between motor controller and battery
  • Need to ask about professional conventions for wiring diagrams

November 29, 2023

As the semester is coming to a close, the Growbot team is hard at work ensuring all project specifications are fulfilled in time. We finished printing the back wheel mounts for the new casters, as well as re-printing new front gears, and all four wheels are now attached to the robot. Several test-runs driving the robot around the lab have been met with some success.

  • The Arduino is being powered by 5V from the motor controller, less than the needed 7V. Thus, the Arduino’s own 5V output is unstable, and likely causing connection issues with the FlySky receiver. When the Arduino is plugged into a laptop via Ethernet (same as when using the serial monitor) it receives enough power to run normally.
  • The robot is not robust enough to drive through unstable ground but it can move forwards, backwards, and turn in both directions within the lab.
  • Some of the old 3d printed parts for the front wheels are cracked, which is causing misalignment in the gears and unreliable movement. We are planning on re-printing and replacing these parts.

In addition, an OSF repository has been created for all current documents of the Growbot: https://osf.io/28dq4/

  • If anything major is modified, it is possible to create a new Registration of the repository to save previous versions.

The Growbot Project began in 2020 with a generous donation from GM, but with multiple changes in team members and re-definitions of the project, GM has not received sufficient updates on the project. So, on Thursday, November 30, 2023, we will be giving a short presentation at the final MTU Enterprise Manufacturing Initiative (EMI) meeting.

We are continuing to work on our final report, final tests of the robot, and the EMI presentation!

Semester 2: Spring 2024

Thursday, January 25

This week, in addition to working on a finished presentation for the next GM meeting on February 1st, I began to look into how other people online have been working on power distribution. For the presentation, we need to finish a Gantt Chart and a budget.

Links to investigate for RC cars and power distribution:

The first page I found was a person detailing the process of revamping an old RC car.

Image credit: https://community.element14.com/challenges-projects/project14/radiocontrol/b/blog/posts/rc-toy-hack—rc-car-rescue-restore-recycle-retrofit

Looking at the image above from the RC car retrofit, the components include a 7.4V Apex Battery, high and a ground rail, all connected to the Arduino Nano, the Qunqi L298N motor controller, and one component I can’t quite identify.

The next page I found shows someone using an ArduPilot board to wire an arducopter.

This page involves someone new to Arduino using an UNO and asking about batteries.

  • One comment by jremington on April 2022 details “Look at the “C” rating for a battery, e.g. 10C. This is approximately the maximum short term current that the battery can safely deliver, in terms of its capacity C, specified by the manufacturer in Ah or mAh. Example: a 10C battery with C=3600 mAh (3.6 Ah) can supply 36 A, for brief periods. 4.8-6V batteries intended for electric RC vehicles are a popular choice.”
  • In addition, jremington states “Search for “arduino external power servo” for many tutorials. Another “gotcha” is that breadboards are designed for low power logic circuits and can’t support high currents for motors and servos. The tracks burn. For many servos, solder power connections, or use a servo power distribution PCB like this one: Servo Power Distribution Board (8 Channel) – goBILDA 2“
  • This is a great starting point for transferring our electronics off of a breadboard power distribution system.
  • Link: https://forum.arduino.cc/t/batteries-and-micro-servos/978441

Hakeem finally solved the age-old issue of the receiver keeping the last value from the controller when the controller is turned off.

Troubleshooting process:

  1. Add 5V line and ground to breadboard.
  2. Plug in the top 5V and GND line to the receiver
  1. Add a cable to whichever channel you want to observe the signal. This is in the bottom 3 rows of pins. Each “column” corresponds to one channel, and the signal is on the top pin.
  2. Hook up one of the signal pins with a cable to the oscilloscope (and ground it on the breadboard)
  3. This should show up as a square wave that “lengthens” as the controller is manipulated
  4. When the controller is turned off, the wave should snap to the default state.

If not, on the controller adjust the failsafe settings.

  1. Turn on the controller
  2. Long press OK to open menu
  3. Navigate to “system” with the up and down keys and press OK to select
  4. Navigate down to RX setup
  5. Navigate to failsafe
  6. Select a channel, then use up and down keys to turn it ON
  7. Do this for all the channels, so they have a percentage next to them
  8. Long-press “Cancel” to confirm

Now, the oscilloscope will show it snapping back to the “default” position when the controller turns off.

In addition, we noticed that the 5V line from the motor controller to the arduino had come disconnected repeatedy. This wire must be replaced.

Next week’s to-do list:

  1. Come up with a potential list of components for the robot
    • Concerns: We will be presenting these as if they are concrete plans, but it is not finalized at all
  2. Add components to planned budget
  3. Organize components by voltage range, to make sure the variety of voltages used on the robot is minimized
  4. Finish presentation for Thursday
  5. Send out invites for Thursday presentation

Tuesday, January 30

This week, we had another presentation with our sponsors at GM. We created a Gantt chart to keep us on track. We received a lot of advice.

  • Testing – ensure it is quantiative and there are several stages throughout the project
  • Power distribution boards – off the shelf boards with built in circuit breaker configurations are likely not cost effective, and it is better to implement cheap automotive fuses
  • Safety – The robot should have a killswitch that is easy to reach

Here are some sources for ways other people have assembled their own power distribution system.

  • Power distribution systems from Dreamworks RC: https://dreamworksrc.com/product-category/default-category/rc-power-distribution-systems/
  • Example of a power distribution box: https://www.reddit.com/r/WLED/comments/yqodvt/my_distribution_box_design_i_hope_this_might_help/
  • An RC car electrical diagram (that has issues): https://www.reddit.com/r/arduino/comments/115na1u/rc_car_electrical_diagram_37v_to_5v_step_up/

To do:

  • All team members should find various components for power distribution, regardless of how realistic or feasable they are. Next week, we will all meet together and compare components and decide which ones would be realistic to implement.

Below is a sketch that was drawn up while we were discussing whether to power sensors off of the Arduino as well as when to step down power. Using a buck converter between sensors and the arduino is a poor idea because it may cause noise, so they will likely be powered by the Arduino’s own 5V line while the arduino is powered by a 7V line.

Wednesday, February 7, 2024

This week, we researched components to add to the upgraded electrical system

Kill Switch – It is important to have a way to immediately turn off the robot, with just the push of a button. Currently, we do have a switch connected directly to the battery, but it is not in the most convenient or reachable location. Thus, having a kill switch in a more accessible location will help with safety. Here are possible kill switches.

Distribution board – Overall, power distribution boards are a way to power things at different voltages without using an excessive number of lines. This Forum from 2021 includes an explanation that regulators are needed for each rail with filler capacitors. I think the capacitors are used to avoid using shunt regulators. A diagram that was attached to this explanation is included below. The diodes from the fuse to the output are included for reverse polarity protection. Essentially, all rails are in parallel from the 12V source, and the regulators are keeping the lines at the voltage needed.

A diagram posted by the user htorju.
They explained that the diodes should be ignored, and instead 12VDC should be plugged in at that location.

For our power distribution, it would make much more sense to use an off-the-shelf power distribution system. We need something that already has regulators included, or a way to adjust them: 12V for motors, 5V for many sensors (including the raspberry pi), and then ~7V+ for the Arduino MEGA.

Fuses

  • Fuse tutorial
    • Calculating what fuses you need: Write down maximum peak power for all devices and use the voltage powering them to get current I=P/V. Then, sum up all currents.
    • Fuse each voltage rail
  • They are stupid cheap, there are probably some in the lab (ask)
  • Physically connecting fuses:
    • 11.00 12 Fuse taps
    • Is this only for cars? Easier way to add fuses?

From my understanding, we will have…

  • Battery > Killswitch > Fuse > 12V rail

From the 12v rail, there will be 2 rails of

  • Fuse > regulator/buck converter > another rail

Should we run the 5v rail off of the Arduino Mega?

February 11, 2024

Today, the job was to find the current needed for each of the fuses on the line.

Fuse 1: 15mA

  • Total value = 2.5m + 2m + 10m = 14.5mA, rounded up to 15mA.

Fuse 2: 400mA

  • This is exclusively for the Arduino MEGA. The mega itself uses 50mA. If it is powering anything on peripherals, their current draw will be included too. Currently, the Arduino MEGA serves as communication between the motor controller, sensors, and the receiver.
  • If the MEGA is being powered by 7V, and the 5V line is being used to power anything, we want the maximum power to not exceed 1 Watt. Many people recommend not using more than 400mA to avoid overheating.

Fuse 3: 14A

  • This fuse is for the entire electrical system, connected directly to the battery. This will require combining the current drawn from all components. The only components not accounted for are the motors themselves, which will be running off of the 12V rail. The motors are “634JSX‑31ZY Motor and Gearbox” with a rated current of 1.6A and a stall current of 6.5A.
  • Currently, we have 2 motors. So, if both are stalling, it would draw 13A. We do not want this to blow the fuse, and we also want to account for the smaller added currents from other components, so this can be rounded up to 14A.

Fuse 3 seems too high. So, we will be measuring actual current draw of the motors next time.

Wednesday, February 14, 2023

Today, Eric and Nasi replaced the wood in the electrical box with plexiglass.

We tested the current draw of our motor and gearbox on its own. This yielded about 0.25A.

Then, we tested the current while it was driving. This was done by connecting a multimeter in-line between the motor and the motor controller, using somewhat haphazard means.

While it was driving, the current would reach 0.61A. All things considered, this was much lower than predicted.

With 2 motors and giving some more “space,” we could use a 2A or 3A fuse for the 12V line.

The sensors all displayed extremely small currents.

The flysky receiver did not go any higher than 0.12A, even when connected to the controller.

The humidity sensor barely reached 0.01A. The specs on the Ultrasonic sensor list they

NOTE:

  • Fuses should be AFTER Regulators on the diagram
  • We need to test the current drawn by the regulators themselves.

To do: Finish critical design review presentation

Monday, 19 February, 2024

Today, I downloaded QCad to make a to-scale version of our distribution system.

In addition, I ordered the following parts:

We also presented our Critical Design Review on Thursday and received a lot of important feeback.

  • Test the current draw from the motors again: In more rough conditions, looking for peaks or spikes, and the “stall” current when the shaft is being stopped forcefully.
  • Consider using “slow-blow fuses” to account for peaks.
  • Consider what fuses to use for sensors
    • Look at the documentation for sensors to make sure that the current does not EXCEED the max current.
    • When would a high current happen? Either from a degrading sensor that would have to be replaced anyway, or a short. In this case, fuses do not have to be as precise.
  • Relays are the only way to implement killswitches. Look into how to do this for sure.
  • Check the current rating of the battery.
  • Simulation can be performed in Multisim as long as the images and documentation is avaliable.

Thursday, March 7, 2024

More parts were ordered:

  • 12 line fuse block – This will be the first area of distribution, our 12V line. This allows fuses to be easily replaced, and even accounting for 4 motors and 1 branching 5v line, still leaves plenty of space for future implementation.
  • Relay – This is the way we will implement our killswitch into the circuit.

We discussed our plans for capstone – Likely, we will spend the first semester working on the drive train, and the second semester working on an end effector or navigation system.

This meeting, we also more rigorously tested the current on our motors. We found that the robot struggled greatly to maneuver over an incline. It likely needs new motors, 4 wheel drive, and no casters.

We found that an individual motor could peak over 1A each, so a 2A fuse is likely too low.

Finally, we found that the shaft for the motor was spinning inside the wheel hub, and we need to find a solution to prevent this.

To do:

  • Create GM Presentation
  • Finish to scale QLab drawing

Friday, March 15, 2024

This tuesday, I finished the electrical box diagram showing all the components to scale. The red lines indicate power lines, but are not indicative of the actual wiring.

In addition, we finished our GM presentation and presented to GM. They gave us a lot of valuable advice.

  • For planning next semester, create a mock gantt chart to what tasks we think will actually happen. If this becomes hard to plan, it is possible our scope is too large and we need to narrow it down. This should happen as soon as possible.
  • We should create a more specific/localized BOM, one document including ALL current parts on the robot including screws, bolts, etc.
  • For issues with the motors/drive shaft, there were several suggestions
    • Set screw in wheel base to stop axle from slipping
    • Drill into the hubs to add a pin

To do:

  • Create gantt chart for next semester
  • Assemble board once parts arrive on Monday

Wednesday, March 20, 2024

  • Our Relay arrived, but not our Fuse Block.
  • We took final images of the design to ensure we have full documentation of all connections, in addition to the wiring diagram.
  • We investigated how to wire the relay, and found the following resources:
    • (Resources will be here soon hold on lol)
    • We contacted the electrical lead, Ben Keppers for help. He gave us advice regarding adding a pull-down resistor and general advice wiring a relay.
  • Finally, we compiled steps required to improve the drive train next semester.

Thursday, March 21, 2024

  • Our fuse block arrived.
  • Wiring
    • We attempted multiple wiring combinations of the fuse block, killswitch, and relay, using a DC power supply supplying 5V as our “Battery.” We stripped wires, crimped connectors to connect directly to devices, and left wires bare where they would connect to the DC power supply, where they would be held together with the alligator clips.
    • Possibly wrong information: We used mostly 18AWG and 20 AWG wire.
    • Shoutout to Nasi for wiring everything very quickly and switching connections as needed.
  • Testing
    • This was tested by placing a fuse in one row of the fuse block and measuring the voltage across it with the multimeter.
    • Then, the killswitch would be pressed, then unpressed. Ideally, the voltage across the ports in the fuse block would be 5V when the killswitch was not pressed, and 0V when the killswitch was pressed.
  • This was the final design that ended up working (below)
    • I’d like to thank Hakeem for getting the resistor in the right combination and James for the moral support.

To do:

  • Continue connecting components and placing them in the electrical box
  • Creating the March 28 Presentation for GM

Thursday, March 28, 2024

This week, we continued with assembly.

After writing down all the Arduino MEGA connections, we detached all components from the electrical box: The breadboard, the arduino, the motor controller, the FlySky receiver, and all sensors. Then, we secured two buck converters to the Fuse block. One buck converter was wired the Arduino MEGA, and the other was wired to a power rail. The FlySky receiver was then attached to the power rail.

  • The gauge of the wire used depended entirely on the kind of connectors that would be secured to the devices. It is possible we may need to modify it later.
  • We used a 1A fuse for both the Arduino and the 5V power rail. We are planning on using a higher amperage fuse for the motor controller.
  • A wiring diagram for the relay was sketched out based on the working configuration.

Currently, all wires and leads are very long. We will have to shorten them to organize better and fit them in the electrical box efficiently.

After our meeting with GM today, we got some advice regarding cable management and wiring.

Then, we tested the distribution system with a DC power supply and setup the buck converters. The FlySky controller and receiver would sucessfully connect, and the oscilloscope revealed it was transmitting the correct signal. In addition, we built the mounting covers onto the buck converter.

Testing Flysky signal

Below is an image of the buck converter cover and all components laid out on top of a cover the size of our electrical box.

Wednesday, April 3, 2024.

We submitted our project proposal for the Fall 2024 and Spring 2025 semester. We began writing our rough draft for our project report. We came up with ideas on what to say in a social media video.

Sketches of drive train for next semester

In addition, we removed the yellow cables for the motors and Nasi soldered longer black and red cables onto them for ease of moving. We helped Eric drill a hole into a plastic cover for mounting the killswitch.

Aftermath of drilling into the plexiglass.

Next time, we will wire the motors to the motor controller and connect the motor controller to the 12 fuse block line.

Thursday, April 4, 2024.

  • We recorded videos for our social media post
  • We finished our initial draft for the final report
  • We wired the motor controller, battery, relay, and motors together
  • We tested the robot: The arduino is now self sufficient, and the robot is able to power itself. The switch turns power on and off, the killswitch immediately cuts all power when pressed.

Monday, April 8, 2024

Today, the team met briefly to plan for the project Check Off. We created our presentation for GM this week, and confirmed which motor on the Growbot was experiencing issues. We noticed the following:

  • The motors were wired backwards: That is, the robot drives in the reverse direction as input on the controller (forward/backwards).
  • The right motor does not engage when the backward motion is input into the controller.

In addition, one of the motor housings cracked, so we re-printed it and have plans to secure it tomorrow.

Tuesday, April 9, 2024

The team performed a project Check-off. We received the following feedback:

  • Next semester, the drive train should be updated completely
  • The following semester, we must decide on one of the following paths for the robot
    • Further sensor integration
    • Autonomous navigation
    • A winch/connector for tilling, water distribution, some kind of platform to further expand functionality

In addition, we found that the wiring between the Arduino MEGA and the motor controller was causing the driving issues from yesterday. It was rectified and the robot now operates as expected.

Thursday, April 11, 2024

Today, we met with our GM sponsors once again. We received the following feedback:

  • Design Requirements
    • Waterproof? – Remove all electronics and test on the robot
    • More advanced text matrix for terrain, repeatable
    • Define “dirty” and whether robot can operate in those conditions
    • If there are failures, plan which direction to turn in
    • Do testing halfway through (week 9ish?)
  • Enough funding for both semesters of capstone?
    • Probably enough for first semester
    • Need to make decision for second semester
  • If there is an issue (cracking housing) what are you doing to ensure it doesn’t happen again – Printing in a different orientation to prevent propogation and using denser infill for strength.
  • Autonomous program can be simple

Advice from Drew

  • Look for an oldDecision matrices around the motors: Fall 2019, Spring 2020
  • 1 year after this, there was a working autonomous
    • ROS done on Raspberry PI in previous year
  • Send the social media video and final report to GM once it has been completed.

To do:

  • Submit updated capstone proposal
  • Continue working on final draft of report, considering peer review feedback
  • Once capstone proposal is approved, register for classes.

Saturday, April 13, 2024

Today, I updated the OSF repository with the new KiCAD file and a new QCAD file.

We continued working on the draft for the final report, and we continued developing our plans for the capstone proposal and submitted it.

Thursday, April 18, 2024

To wrap up the semester, we took into consideration the feedback given in the peer reviews over the past few weeks, and using it we finished our Final Report. In addition, we made our new OSF repository pages public. We discussed the directions for next semester. More specifically…

  • We decided to go with a 4-wheel design for the drive train next semester
  • We discussed having more specific and outlined roles for everyone on the team so it is very clear what everyone contributed to the team
  • We want to have our decision making done as soon as possible so we can immediately begin ordering parts and begin testing halfway through the semester.

The individuals at GM graciously gave us permission to add their names to our report in the Acknowledgements section.

Overall, this semester was a great learning experience, and we managed to complete all of our goals. It has been truly exciting seeing everything come together and have the robot be able to power itself independently. It was quite a challenge to figure out the design for the relay, but seeing it work was very satisfying. The team is feeling very confident about the direction of the project and we are excited to continue working on it for our Capstone next semester.