Over the last two weeks, I worked individually on multiple software components and worked with the team to test out some of the hardware.
I created a more rigorous test to make sure the algorithm returns the optimal path, but it wasn’t optimal at first. I debugged and fixed the multiorder algorithm, as there was an internal hashing function for the robot’s partial state that was colliding and causing some states to not be visited in the calculation.
I started on the GUI for the emergency operator and the user, and combined it with the ground station (multiorder node) so that the GUI can place orders for a ground station to send to a simulated robot.
The emergency operator GUI has a camera feed and takes in joystick controls to send to the robot, and the user GUI can take in and send orders to the ground station.
Working with the team, I helped out with the robot FSM, and based on that I redesigned the multiorder node/ground station to match the interfaces that the robot now requires.
I worked on figuring out how to calibrate the Adafruit IMU on the Jetson, and helped Advaith with RTABMAP/network testing outdoors with the Jetson.
Progress:
Currently I am on-track, despite our waiting for the Roboclaw to arrive- instead, we worked on software to balance out our progress.
Next week’s deliverables:
When the Roboclaw arrives, we have to make sure that the ground station can manually drive the robot around the campus.
I’ll continue to add more features to the GUI, and make sure that the ground station works in production.
Finalized robot state machine specification with team (services vs topics)
Wrote initial implementation of the robot state machine
Progress Timeline
Our progress is on schedule
Next Week Deliverables
Test the robot state machine and integrate it with the local planner
Explore a new ROS architecture with multiple networks, since the robot loses connection to CMU WiFi while moving. We would like to put a hotspot on board.
For some reason, when we tried to connect to CMU-DEVICE, we could not resolve DNS or ping outside IP addresses. After many hours of debugging the only solution found was spoofing the MAC address of our dongle.
Integrated Joystick controller into ROS
Used a library node + a thin wrapper (written by me and Michael) to map controller inputs to the Roboclaw
Began integration of GPS on the Xavier
Progress Timeline
Our progress is on schedule
Next Week Deliverables
Work towards completing our first milestone – driving the robot with a joystick, and receive a video-feed
We received many parts this week, and we spent the majority of time testing them individually. We tested the motors, motor controller, robot/groundstation networking, and collision avoidance algorithm in simulation.
Current Risks and Mitigation
The Jetson Xavier is having issues with the RealSense D435i. It will reboot after running for what seems like an arbitrary amount of time. Additionally, the framerate is still lower than expected, likely due to using a default configuration.
We’ve seen other people use the same camera running RTABMAP at reasonable framerates, so we are going through forums looking for solutions
The motor controller disconnects easily when using USB connection for serial.
To fix this, we are moving towards a wired UART connection to the motor controller
Changes to System Design
Interface between Xavier and motor controller changes from USB Serial to UART.
This week, I made the multiorder algorithm an optimization algorithm- now, it not only finds a satisfactory list of moves such that the robot can deliver all orders on time, but also if finds the path that has the minimum total distance travelled.
The algorithm uses dynamic programming to find the optimal path. The reason DP works on this problem is because the batch of a orders for a robot is constantly and always decreasing, so we know that the optimal solution for any given robot state is the minimum of all subsequent robot states that come from doing an allowed move + the cost of the action to reach that robot state; therefore, this problem shows very clear optimal substructure. We can base the new algorithm off of that recurrence relation and memoize to never repeat calculations and shave off complexity from a scale of n! to c^n (for some constant c).
I haven’t done any proof of the complexity yet, but hopefully I can do it at some point this semester.
This involved creating a hash of the robot state in order to allow for memoization of repeated states, and a modification of the internal function to pass back the optimal path at each subproblem.
Today I also worked with my team to begin assembly of the robot. We found a Roboclaw ROS Node that provides a wonderful interface for PID low-level controls and encoder odometry on the Roboclaw and its motors, so I got that up and running- we can now send a velocity message to it and the wheel will turn accordingly with the velocity!
I also worked on inspecting and testing the battery to make sure it was functional and intact with the voltage tester that we bought.
Progress:
I am currently on-schedule with my tasks.
Next week’s deliverables:
Next week, I want to fix a bug we have with our Xavier where it self-reboots seemingly arbitrarily and make sure (rigorously) that the optimization version of the multiorder algorithm is working correctly.
This week was spent choosing parts and finalizing the design
Current Risks and Mitigation
We iterated on the design several times, and decided that choosing motors that could carry the 2kg payload will require higher end motor controllers and would violate the budget.
We decided to relax the requirement to travel on slopes on campus, and focused on flat areas only. This way, we could bump down our motor specs and meet the budget constraint.
Torque/motor = 0.5*Fr = 0.5*mgkr = 6.585 kg*cm
RPM = (60*v) / (π*2r) = 139.2 rpm
After finishing an initial design of a custom chassis, we decided to keep it simple and use a premade chassis. This will save a bit of money and save a lot of time that can be spent polishing our software.
Our TA brought up that visual SLAM may not work well outdoors. We mitigated this by adding an LED ring light to our design. (will be presented in design presentation)
Changes to System Design
We’ve decided on using a premade chassis.
Our campus travel requirement has been relaxed, specified in the above section.
Schedule Changes
No changes to our schedule this week.
Progress Pictures
This is Advaith’s CAD rendering of the new robot model using a premade prowler chassis, a wooden platform and a plastic holding device.
This week was spent really finishing the design and making changes to the requirements. We spent a majority of the time massaging the budget constraint and choosing parts that would satisfy it.
Performed calculations for parts finalizing
Finalized the CAD design and finished the BOM for the chassis
Ordered all the parts on our BOM
Finished the design presentation and have practiced
Schedule Progress
We are on schedule for our project. We ordered parts and they will be arriving by the end of next week.
While we wait for parts we will begin to build out the software systems in simulation.
Deliverables for Next Week
Finish proof of concept for collision avoidance algorithm
Finish the design presentation and practice giving it using the feedback from the last presentation
This week, I finished up the global planner implementation and tested it.
The global planner batches orders to plan for the robot’s waypoints, and can take in orders online.
I tested it by writing a “simulated” robot ROS node that takes waypoints and sends back location updates to make sure that the global planner node works. It just instantaneously teleports to the waypoint, essentially.
I plan to make the robot a bit more rigorous by having it simulate “driving” to the waypoint with ROS::Duration::sleep.
The global planner might be done, but there’s a lot of things I can do to make it more robust.
I know how to make it give a better route by returning the minimum route across every searched path, but that may drastically increase the runtime as it must search ALL paths and not just return the first one.
I feel like this is optimal, and I thought about proving it by inducting on the list of orders somehow, but it seems pretty hard to prove that this is optimal.
I discovered some dynamic programming potential here, by memoizing a hash of the robot state to take advantage of any repeated searches (however, I have to write a hash function for the robot state first haha).
Worked on design presentation and helped with parts ordering
Progress:
I am currently on-schedule with my tasks.
Next week’s deliverables:
Next week, I want to write some more rigorous tests and make it an optimization problem by minimizing the overall distance + make it DP.
