Jasons’s Status Report for 11/2/24

WORK ACCOMPLISHED:

This week, we focused on getting motor movement from a python script. While we struggled with this initially, we managed to get a response once we switch from connecting from the GPIO pins on the Rpi to the COMM ports on the vesc to using the USB ports on both. Prior to this, we attempted sending signals via pyvesc, sending independent UART signals, and sending PWM signals. We are now able to control each motor independently and I have tinkered with acceleration and deceleration curves and have tuned to a point where we can begin testing. I will further refine once we have mounted. Currently, I have a test bench in which I control motors with keyboard interactions. The only thing left to solve in simultaneously control which I believe we will be able to do with multithreaded listening for commands for each motor.

PROGRESS:

We are a little behind schedule. The documentation for pyvesc is very skim and it appears projects like this are quite rare. As a result, it is taking longer than expected to navigate this package and figure out some intricacies.  Getting a response from the motors is a huge step forward and unlocks so much more for us now. We will likely be able to make very large bounds in the next few weeks.

NEXT WEEK’S DELIVERABLES

We will have app to motor response, rudimentary turning, and a jank assembly of the board complete.

Jason’s Status Report for 10/26/2024

WORK ACCOMPLISHED:

This week I focused on starting the assembly of our parts. I soldered bullet connectors onto our VESC to allow it to connect to the motors. I soldered the VESC to the anti-spark switch which connects to our power button and prevents surging when the battery is initially powered on. I soldered the anti-spark switch to an xt60 connector which allows us to connect to the battery. Ultimately, we were able to power on the VESC, making a huge progress step for us.

PROGRESS:

We are slightly behind on tasks but should be able to make significant progress this week. I have been slightly delayed by one part taking longer than expected to arrive but have been preparing in the meantime. The next steps are to test the python code I have written on the VESC. Currently, I am blocked by a part that connects the motors to the VESC and thus I am unable to presently test the Pi-VESC communication.

NEXT WEEK’S DELIVERABLES

The missing part is expected to arrive this weekend. When it does, I will begin testing and tuning the Pi code. Next week, I expect to be able to control motors from the webapp and begin setting acceleration curves in preparation for mounting on the board.

Jason’s Status Report for 10/19/24

WORK ACCOMPLISHED:

I dove back into VESC software and realized we may not be needing it but will likely instead be replicating the functionality. 

One crucial component when using VESC software is motor configuration. Above is a screenshot of the VESC software. When setting up the VESC with this software, we are setting important things such as Voltage Limits, Current Limits, Motor RPM Limits, Temperature Limits, Motor Tuning, Startup Boost, and Regenerative breaking. In the absence of a VESC, my plan to tackle each of these is as follows:

Voltage Limits/ Current Limits: We will calculate our battery and VESC’s voltage limit and place ceilings on the speed of the motors relative to the cap we impose to make it physically impossible to exceed our limits, even at maximum motor speed. In the case where this is not possible or does not prove to be effective, we will add external current-limiting circuits with a current/voltage sensor.

RPM: We will use Hall sensor data to keep a close watch on the RPM and throttle if we exceed a certain limit we will impose. This can be done through RPi packages.

Temperature: Similar to RPM, our hall sensors will allow us to understand the temps of our motors at any given time. We will have a circuit-breaker esque trip system that will cause the board to slowly come to a stop if we exceed same measurements.

Motor Tuning: We will likely have to measure the motors with an LCR to determine the resistance and inductance to help define how we will set our acceleration curves.

Startup Boost: When in the initial phase of the motor, we will supply slightly extra current to avoid dead-stop stalling.

Regenerative Breaking: We will not be incorporating this feature.

 

PROGRESS:

I am on track with my goals as set out by the Gantt chart. I am somewhat blocked in waiting for the VESC to arrive to begin applying the theory and ideation to a practical and testable environment to begin making adjustments as necessary. When we return to school, I will be able to work on this in a much more effective and efficient manner.

 

NEXT WEEK’S DELIVERABLES:

  1. Assemble as much of the board as possible.
  2. If the VESC is here, begin running tests and playing around
    1. Specifically decide concretely about UART vs PWM.
  3. Ensure we are able to read data from the Motors and send it back to the RbPi.

Jason’s Status Report for 10/5/24

WORK ACCOMPLISHED:

Part list changes: We elected to convert from our existing GPS IMU selection here: https://www.sparkfun.com/products/16329 to this one: https://www.sparkfun.com/products/22693.  The course staff chose to buy this and it outperforms our old pick significantly. The last option provided 2.5 meter accuracy and the new one is 0.01 meter accuracy, which allows us to meet our user requirements. The only consideration here is that the data output is slightly different so we will have to adjust our method of processing. This also frees up more budget to allow us to get closer to the $600 mark. We also swapped to a new LiDAR that the course staff provides. The new LiDAR does not connect directly to our Qwiic parts so we will be swapping to a USB-C to connect.  This also saves us significant budget.

We also solidified a number of connections and finished ordering parts. Once the parts arrive, we will be able to further solidify the designs. I plan on tinkering with all the parts in the lab to get a better understanding of how each one works and the data output we can expect from each one. The finalized parts list is here: https://docs.google.com/spreadsheets/d/1ouYsHj6s2zO1oddGNwvI4KCI4vJLrQ7ma_3bCsAnZ94/edit?gid=0#gid=0

The last major design change was a transition to a external battery pack to power the Raspberry Pi. We are concerned about splitting power from the huge pack so we are using an external pack. We could not find a 5v/5a external pack so we converted to a Raspberry Pi 4 instead of 5 to make it more accessible for common power packs. The only concern here is we will have to drill an additional hole in the enclosure to allow for charging. In addition, having 2 chargers is a little bit of an inconvenience.

I also did a preemptive diagram of all of our connections and the ports to ensure each one is compatible and able to transfer the data and power that we need.

PROGRESS:

I am on track on progress despite taking longer than expected to finalize the parts list. We went through a number of iterations including frequent group meetings, a meeting with Joshna, and frequent discussions with professors after class.

 

NEXT WEEK’S DELIVERABLES:
The next step for me is to receive the parts and start piecing things together to get closer to the final product. I will continue to help my team with app design, LiDAR sensing, and GPS mapping. The biggest task next is to figure out the autonomous steering mechanism and the communication method between the RbPi and the VESC. Before the parts arrive, I will familiarize myself with the open source VESC software to be prepared to jump in when all parts are here.

Jason’s Status Report for 9/28/24

WORK ACCOMPLISHED:

Further research into part compatibility has demonstrated the following problem. As we are already facing budget concerns, we are very mindful of any increases to our total costs. I discovered that the battery we selected does not come with a bms or battery management system, a critical component for obtaining live data with regard to battery charge. As this was one of the core requirements we set out for ourselves, we want to push to accomplish this goal.

Our current battery is 10s2p which means 10 in parallel, 2 in series for a total of 20 batteries at $90. Moving to a pack with a bms even at 6s2p, which is 12 batteries brings us up to $185 as seen here: https://www.mboards.co/collections/batteries/products/6s-p42a-battery-pack-transparent-series with very little opportunity for other options.
As a result, we remain undecided.

We consistently have to make tradeoffs between reputation and performance.   For instance, we are able to buy more powerful motors with hall sensors here https://www.amazon.com/Brushless-Belt-Drive-Balancing-Scooters-Skateboards/dp/B07RXWW3DS/ref=sr_1_12?crid=2NEHK9FI43FHT&dib=eyJ2IjoiMSJ9.6_nUl4ZD3ZhjtZRfEZjPpPkI-0W-ird_zf3qSUvrDoYUGkNTVwylh-QgjidNUhGbBe8Qa_XTIE045heaKbB5qKbSCZ6tp3QndVmnl9liKLtqRwtL1AC–_CNs96VuNbYgxfPJvtUo_kl6qI-aVew-xXCn2bupq9aYjwABIzz8FzucCxE36cwUdnpagXtLfcBK5erniMT3015ZyDPIe9Mm4gaoM9hpidCoyrb6UavlVlui1HrwVHDXP2RGIHHI577Q3uZjiODNIhXDbX7rnCcJO6g-03lSZ_WOywLBtRB8rw.E1N2p-XUPUVELYuiIRbatHIXFuBrgDPEFet7I_SFGso&dib_tag=se&keywords=skateboard%2Bmotor%2B6354&qid=1727576364&sprefix=skateboard%2Bmotor%2B6354%2Caps%2C116&sr=8-12&th=1
but without the ratings and brand reputation that our other option gives us.

On top of this, I researched the charger for our battery, antispark switch to power the board, and explored the wirings for our VESC and made note of some converters we will need to purchase.

I also looked into the truck/motor mounting system and found

which we will likely use as it appears to be relatively plug and play

DISCUSSIONS:

I researched the communication methods between the Rpbi and VESC and landed on using UART. Theoretically, we can use UART to send motor speed, temperature, and others to the Rbpi and receive throttle, braking, and other commands back. There is a python module called pyvesc that will allow us to do this seamlessly.

The VESC does not explicitly list compatibility with UART but says it is compatible with VESC software. In the case it is not compatible, we will definitely be able to send PWM signals to the motors from the VESC using RPi.GPIO python module and the GPIO ports on the Rbpi.

I also discussed path planning with Tio and the team and landed on a project of GPS down to a 2d box in which we will use basic x,y coordinates to reach the target.

PROGRESS:

 

I am still on track as my task this week was to select the path planning algorithm.

 

NEXT WEEK’S DELIVERABLES:

Next week, my sole goal is to fully and completely finalize the parts list. There is still considerable work to be done on this front and I hope we are able to get this done so we can move on to the actual implementation. This has proved to be significantly more difficult than expected.

 

Jason’s Status Report for 9/21/24

WORK ACCOMPLISHED:

Landed on a solidified architecture for controller to board communication.
The flow will be as follows.

In the event of normal riding, our flow will be input from user on webapp -> bluetooth communication to raspberry pi -> raspberry pi to VESC communication of signals -> VESC to motors

In the event of the “return to me” feature, our flow will be input from user on webapp -> bluetooth communication to rasberry pi -> input from LiDAR sensor to raspberry pi -> path planning calculation on the web app -> directions sent to raspberry pi -> directions sent to VESC -> directions sent to motors.

 

Part Selection:

  • Landed on an almost-final version of the parts we will be employing.
    • VESC: https://flipsky.net/products/dual-fsesc4-12-100a?variant=9022834638908&currency=USD&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic&gad_source=1&gclid=CjwKCAjw0aS3BhA3EiwAKaD2Zd5iglwJYeZaNOX5BAR4TkeQuqevF_zDt3az7iHfjzF1aVxhLHioOhoC1rkQAvD_BwE
    • 2x 5055 motors: https://www.amazon.com/Hobbyhh-Brushless-5055-400KV-Efficiency-Aircraft/dp/B09BYVKZ5W/ref=sr_1_2?crid=F1IOMBUFCJGT&dib=eyJ2IjoiMSJ9.YIcSePfgaVsN6txie0egmwsARIbLiLZgkDep_XMtgkBZ48uyUE-Bgfs2PnUpL4Tzld0_cKCw4WfuliYydziJmzvCVVH7j8HK2DLiDKXKFYpvkwgklkCSKVAfWKhmS51yGr04LtxTChMIHHGz2P-7HteXbZ5jz4_VQE1rC8LA2kruijlqTRfQe7ytiWh-B36U59Fcbog-XeS5GYgmFXH0S-JPCSWt8fuD1-8DCrpFwQ4eO9xw7Iw0vmxQUxG7mOkWmbkssPNsyoN1JPxpTmU12v4wypoSK778X7mkfMDxETg.V86EyqCGVVZR9GmM6c0lQvJXmOMAs4k0VaUqd1ns8YU&dib_tag=se&keywords=5055+motor&qid=1726985746&s=toys-and-games&sprefix=5055+motor%2Ctoys-and-games%2C289&sr=1-2
    • The build above minimized spending but allows us to meet the requirements we specified in our abstract and in our proposal presentation

Discussions:

  • More info about architecture: The VESC turns out to be necessary due to power consumption concerns: the raspberry pi is unable to regulate and control the amount of voltage and current needed to power the motors. As a result, we cannot circumvent the VESC and must use a rbpi alongside a VESC.
  • On the topic of belt driven vs hub motors, I have elected to go with belt motors as we likely cannot sustain the cost of hub motors. Above is the candidate I have chosen. We are sacrificing ease of configuration for cost and potentially slightly more torque.
  • There are a variety of open source path planning algos but for our sake, I think ML may be unnecessary as we plan to essentially implement a simple “back up and reroute” algo. As a result, I have elected to largely ignore available path planning algos.

PROGRESS:

I am on track as I was supposed to explore path planning algos and assist with part planning and both of those items have been accomplished.


NEXT WEEK’S DELIVERABLES:

Next week, I aim to complete the following:

  • Have a more concrete and mathematical approach to the path planning algo including GPS movement from point A to point B, object sizing algorithm ideas, and ideating on how much to back up in the case of an obstacle occurrence.
  • I want to get my team approval on my parts selection and submit it to the TA for ordering
  • I will also help prepare design presentation slides and write speaker notes to help whoever presents
  • I will also continue to coordinate with professors and our TA as well as make relevant updates to the slack and website