Got the Roboclaw running the motor and getting encoder values
Shortly after, the Roboclaw we had stopped working. I suspect that the USB port is messed up, or that we accidentally damaged it during our testing, but we weren’t able to connect to the software to update the firmware/debug either (so I suspect it is a USB port issue). We have ordered a new one arriving 3/31.
To prevent any further damage to the new roboclaw, we are following the instructions on the manual for operation strictly.
I finished the mechanical part of the robot, including sensor mounts, wiring,electronics mounting, etc.
Wrote a ROS node that can perform object detection using the YOLO CNN
Tested the RTABMAP algorithm outdoors using the robot’s compute. FPS runs fine, however, there are some issues with tracking when it viewed sidewalks with not many features. We believe this problem might get better if we include the IMU, GPS sensors as well. We will retest once we have the motor controller so we can drive around.
Schedule Progress
We are slightly delayed on our first milestone (joystick moving the robot) because of some issues with the Roboclaw motor controller. However, we tested on the previous one before it failed, so we are confident we can integrate it quickly.
Deliverables for Next Week
I wish to bring in all the sensors for state estimation, and make sure the visual slam works properly
Finish the pedestrian detection and tracking pipeline.
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
Finished initial implementation of the local planner in simulation. The robot can avoid obstacles while still going through waypoints
Assembled robot base hardware.
Helped test the motors and motor controller
Tested the GPS sensor’s raw data output on campus sidewalks
This looks promising, as GPS is usually accurate to 3-5m. These data are within the sidewalks most of the time, and I think combining this with wheel odometry and IMU data can lead to accurate localization.
Schedule Progress
We are on schedule for our project. We got the parts and have made good progress this week on our deliverables
Deliverables for Next Week
Run the localization algorithm independently using the IMU, GPS, and camera
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
