Project

# Title Team Members TA Documents Sponsor
34 Basketball fetcher drone
Louie Davila
Patrick Sarad
Yinshuo Feng
Sainath Barbhai design_document1.pdf
design_document2.pdf
other2.pdf
other3.pdf
other4.pdf
photo1.JPG
photo2.jpg
video
# Project title: Basketball fetcher drone

Team Members:

- Luis Davila (ldavila2)
- Yinshuo Feng (yinshuo3)
- Patrick Sarad (psarad2)

# Problem

When it comes to any sport, people typically like to practice certain skills over and over in order to better master them. One such skill that people like to practice is shooting a basketball from different spots on the court. However, anyone who has done this has definitely come across the issue of having to run back and forth retrieving their ball after taking each shot. This results in more time running for the ball than actually shooting it.


# Solution

Our solution to this problem is a drone that uses pincers to keep a spare ball or fetch a ball for the user. The user will be wearing APRIL tags so that the drone can identify them. The ball will be spray-painted to be a distinguishable color so that the drone can identify it.

The drone software will be on an Arduino and a PCB, which will control a 4WD car for movement and pincers attached to the front for grabbing/holding a ball. Control commands will be issued based on inputs from a camera and an ultrasonic sensor.

The drone will use a camera to identify the ball, the user, and the waypoint from which it will wait for a ball to fetch. The drone will start to fetch a ball if it is detected below a user-specified threshold in the camera view. When the drone is close enough to a ball, it will use the front-facing ultrasonic sensor to determine when the pincers should be closed in order to grab the ball.



# Parts Needed

2-level RC car chassis
1 Ultrasonic sensor to approximate distance
1 Arduino camera module
4 Motors for the wheels
2 Motors for ball grabber
6 rechargeable 9V batteries (1 per motor)
Apriltags for user and waypoint recognition
Arduino
PCB


## Control subsystem

Software on the Arduino will process sensor and camera data and send the results to the microcontroller on the PCB, which will use these results to control the motors. Once the ultrasonic sensor detects the ball within a certain threshold, another signal will be sent to the PCB to engage the pincers to trap the ball.

The PCB itself will be used to control the different motors on the car (all the motors connected to the wheels as well as the motors operating the pincers). Along with this, the ultrasonic sensor and the camera will be connected to the PCB. The ATtiny85 microcontroller will be used to control the 6 motors on the drone.


## Ball tracking subsystem

The drone will come with an APRIL tag that will mark the location that the drone must return to after completing the ball fetching subprocess. This APRIL tag should be placed as follows:
1. The tag must be facing the court
2. The tag must be behind the hoop
3. The tag and the court should be separated by a distance greater than the length of the drone

The user must then manually select a threshold on the camera view. If the ball is detected below the threshold, the drone will begin the ball chasing process.


## Ball chasing subsystem

When the ball is detected below the manually selected threshold in the camera view, the drone will take one of 2 actions. If it is holding a ball, it will deliver its ball to the user before fetching the ball that was detected. If it is not holding a ball, it will fetch the ball that was detected. The drone will remember which action it takes at this stage until it completes the ball fetching process.


## Ball fetching subsystem

Initially, the drone will rely on the camera to get closer to the ball. Once it is sufficiently close, data from the ultrasonic sensor will be used to get close enough for the drone to acquire the ball.

When the ball is close enough to be acquired, motors will close the drone's pincers so that the ball is able to roll, but is confined to the space in between the pincers.

Once the ball is acquired, the drone will take one of 2 actions. If it gave a ball to the user in the ball chasing process, then it will return to the user-selected waypoint defined in the setup of the ball tracking subsystem. If it didn't give a ball to the user, it will give the ball that it just fetched to the user and return to the user-selected waypoint. Upon reaching the waypoint, the drone will rotate until the user is on the camera. If both the ball and the user are on the camera, the drone will stop rotating. If only the user is on camera, the drone will continue rotating until it finds the ball. If only the ball is on the screen, the drone will stop rotating and use the threshold to determine whether or not to initiate the ball chasing process.


# Criterion For Success

An “objective” refers to any one of the following: the user, the ball, or the waypoint.
1. The drone can control the motors to travel towards an objective
2. The drone can use the sensor and camera to search for an objective.
3. The drone can slow itself down as it gets closer to an objective, and stop itself before colliding with the objective.
4. The drone can control the pincers to acquire a ball using data from the sensor to approximate the position of the ball relative to the pincers.
5. The drone can control the motors and pincers to deliver an acquired ball to the user.
6. The drone can complete the chasing sequence and the fetching sequence and return to its initial ball tracking state.


# Link to project repository

https://github.com/ldavila17/sp2023-445

ATTITUDE DETERMINATION AND CONTROL MODULE FOR UIUC NANOSATELLITES

Shamith Achanta, Rick Eason, Srikar Nalamalapu

Featured Project

Team Members:

- Rick Eason (reason2)

- Srikar Nalamalapu (svn3)

- Shamith Achanta (shamith2)

# Problem

The Aerospace Engineering department's Laboratory for Advanced Space Systems at Illinois (LASSI) develops nanosatellites for the University of Illinois. Their next-generation satellite architecture is currently in development, however the core bus does not contain an Attitude Determination and Control (ADCS) system.

In order for an ADCS system to be useful to LASSI, the system must be compliant with their modular spacecraft bus architecture.

# Solution

Design, build, and test an IlliniSat-0 spec compliant ADCS module. This requires being able to:

- Sense and process the Earth's weak magnetic field as it passes through the module.

- Sense and process the spacecraft body's <30 dps rotation rate.

- Execute control algorithms to command magnetorquer coil current drivers.

- Drive current through magnetorquer coils.

As well as being compliant to LASSI specification for:

- Mechanical design.

- Electrical power interfaces.

- Serial data interfaces.

- Material properties.

- Serial communications protocol.

# Solution Components

## Sensing

Using the Rohm BM1422AGMV 3-axis magnetometer we can accurately sense 0.042 microTesla per LSB, which gives very good overhead for sensing Earth's field. Furthermore, this sensor is designed for use in wearable electronics as a compass, so it also contains programable low-pass filters. This will reduce MCU processing load.

Using the Bosch BMI270 3-axis gyroscope we can accurately sense rotation rate at between ~16 and ~260 LSB per dps, which gives very good overhead to sense low-rate rotation of the spacecraft body. This sensor also contains a programable low-pass filter, which will help reduce MCU processing load.

Both sensors will communicate over I2C to the MCU.

## Serial Communications

The LASSI spec for this module requires the inclusion of the following serial communications processes:

- CAN-FD

- RS422

- Differential I2C

The CAN-FD interface is provided from the STM-32 MCU through a SN65HVD234-Q1 transceiver. It supports all CAN speeds and is used on all other devices on the CAN bus, providing increased reliability.

The RS422 interface is provided through GPIO from the STM-32 MCU and uses the TI THVD1451 transceiver. RS422 is a twisted-pair differential serial interface that provides high noise rejection and high data rates.

The Differential I2C is provided by a specialized transceiver from NXP, which allows I2C to be used reliably in high-noise and board-to-board situations. The device is the PCA9615.

I2C between the sensors and the MCU is provided by the GPIO on the MCU and does not require a transceiver.

## MCU

The MCU will be an STM32L552, exact variant and package is TBD due to parts availability. This MCU provides significant processing power, good GPIO, and excellent build and development tools. Firmware will be written in either C or Rust, depending on some initial testing.

We have access to debugging and flashing tools that are compatible with this MCU.

## Magnetics Coils and Constant Current Drivers

We are going to wind our own copper wire around coil mandrels to produce magnetorquers that are useful geometries for the device. A 3d printed mandrel will be designed and produced for each of the three coils. We do not believe this to be a significant risk of project failure because the geometries involved are extremely simple and the coil does not need to be extremely precise. Mounting of the coils to the board will be handled by 3d printed clips that we will design. The coils will be soldered into the board through plated through-holes.

Driving the inductors will be the MAX8560 500mA buck converter. This converter allows the MCU to toggle the activity of the individual coils separately through GPIO pins, as well as good soft-start characteristics for the large current draw of the coils.

## Board Design

This project requires significant work in the board layout phase. A 4-layer PCB is anticipated and due to LASSI compliance requirements the board outline, mounting hole placement, part keep-out zones, and a large stack-through connector (Samtec ERM/F-8) are already defined.

Unless constrained by part availability or required for other reasons, all parts will be SMD and will be selected for minimum footprint area.

# Criterion For Success

Success for our project will be broken into several parts:

- Electronics

- Firmware

- Compatibility

Compatibility success is the easiest to test. The device must be compatible with LASSI specifications for IlliniSat-0 modules. This is verifiable through mechanical measurement, board design review, and integration with other test articles.

Firmware success will be determined by meeting the following criteria:

- The capability to initialize, configure, and read accurate data from the IMU sensors. This is a test of I2C interfacing and will be tested using external test equipment in the LASSI lab. (We have approval to use and access to this equipment)

- The capability to control the output states of the magnetorquer coils. This is a test of GPIO interfacing in firmware.

- The capability to move through different control modes, including: IDLE, FAULT, DETUMBLE, SLEW, and TEST. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to self-test and to identify faults. This will be validated through debugger interfacing, as there is no visual indication system on this device to reduce power waste.

- The capability to communicate to other modules on the bus over CAN or RS422 using LASSI-compatible serial protocols. This will be validated through the use of external test equipment designed for IlliniSat-0 module testing.

**Note:** the development of the actual detumble and pointing algorithms that will be used in orbital flight fall outside the reasonable scope of electrical engineering as a field. We are explicitly designing this system such that an aerospace engineering team can develop control algorithms and drop them into our firmware stack for use.

Electronics success will be determined through the successful operation of the other criteria, if the board layout is faulty or a part was poorly selected, the system will not work as intended and will fail other tests. Electronics success will also be validated by measuring the current consumption of the device when operating. The device is required not to exceed 2 amps of total current draw from its dedicated power rail at 3.3 volts. This can be verified by observing the benchtop power supply used to run the device in the lab.