Research and planning was done to determine the scope of the project:
Create initial list of requirements, constraints, and parts
Meet as a team to examine the existing platform and determine what could be reused
Meet with Dr. Winfree to confirm requirements and constraints
Research methods of developing adaptable platforms, measuring data related to object avoidance, speed,
and distance, and creating user interfaces
Break down project into subsystems and divide the workload
Build prototypes to simulate key aspects of subsystems
Meet with Krista Branch to refine requirements and constraints
Research additional parts needed to construct final product
There were many design decisions that influenced the project's development:
To satisfy the need for object detection and distance calculations, we originally chose to use LIDAR and infrared (IR) sensors in tandem. However, we felt that LIDAR was more complex and difficult than the project required, so we chose to implement a combination of IR sensors and an accelerometer.
To implement user configurable inputs while staying at a reasonable budget,
we decided to reuse the standard joystick and head switches that were attached
to the previous implementation of the platform. The client did not see force
feedback as a point of interest, so we opted not to use the force feedback
Sidewinder joystick.
To allow for easy readability when adjusting parameters, we decided to
develop our GUI in Processing, an IDE that uses Java programming.
To maintain a cost-efficient platform with electronics we have prior
experience with, we chose to use an Arduino Uno.
To provide a smoother and safer riding experience for the user, we had to
order new motors and provide a way to shut off the platform in case of emergency.
Several problems arose throughout the project:
Due to class schedules, research, off campus jobs, and other circumstances,
it was difficult to schedule time where the entire team could meet together. To
overcome this, we were consistent and thorough in our communications with each
other. Every meeting would have someone taking notes, which could then be
distributed to members who were unable to make it.
Purchasing delays often put us behind schedule in terms of physically
assembling the final product. To make up for this, those whose systems were
waiting on parts would be doing research on implementations, or asking other
members how they could help speed up other parts of the project.
Force feedback and object avoidance specifically were listed in our
requirements, but the provided force feedback joystick was sluggish and often
listed to one side while inactive. After speaking with our client, these two
requirements were determined to be not actually what the client needed. With
that in mind, we turned our attention to other aspects of the project.
Wireless connectivity was one of our primary requirements. However, establishing a connection proved to be more difficult than anticipated. With that in mind, we tried to develop a mount where the host PC could attach securely to the platform and maintain wired connectivity. However, this turned out unsuccessfully, so this will be something considered for future work.
Early prototyping was done to determine the validity of our initial implementations:
To test our original driving scheme for the joystick, we built a small-scale prototype to simulate our platform. This test was deemed a success, as the motors and wheels were able to move as we intended them to.
To ensure we could collect and display accurate data in real time from a sensor, we built a prototype that measured distance and displayed a graph to the screen. This test was deemed a success, as the graph fluctuated depending on where an object was placed relative to the sensor itself.
To determine whether our control scheme for sending and receiving data at the host PC would work, we built a prototype that sent control signals to a circuit setup from the host PC, based on a mouse click command. This test was deemed a success, as the scheme we had planned was correctly demonstrated by the external components we chose.
Due to the physical distancing guidelines resulting from COVID-19, testing of the full platform
was a bit different than expected:
We had multiple inputs and driving modes planned, but needed to test them individually so that we could ensure proper operation with each mode separately. To do so, we programmed our Arduino with one scheme at a time, then tested to see if it could control the platform appropriately. This test was deemed a success, as each driving mode worked individually.
We wanted to collect multiple types of metrics from the same data (distance, and possibly speed), so we needed to write code for not only a distance sensor, but an accelerometer as well. As with our driving modes, we programmed our Arduino with calculations for one metric at a time, and slowly built more in. This test was deemed a success, as we were able to accurately measure distance by placing objects in front of the sensors, whether the platform was stationary or in motion.
We needed to test whether our final interface was capable of interacting with the platform correctly. This included sending a control signal to determine the driving mode, receiving data from the onboard sensors, displaying and saving the calculated data to the host PC. To accomplish this, sample Arduino code was written with an ultrasonic sensor, and run alongside the GUI. This test was deemed a success, as two-way data transmission was achieved.
Finally, we needed to test our full system. This included proper transmission of a command signal from the host PC to the platform, correct driving mode based on the signal provided, transmission of sensor data back to the Arduino, data sent back to the host PC, and displaying and saving of data. To do so, we uploaded a full version of code to the Arduino, ran our full interface, and mounted all the sensors and drivers we planned to use in the field. This test was deemed a success, as full functionality was achieved.