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 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.
In our initial testing, running SLAM on the Xavier using the ZED mini had low fps (10). Advaith found that many people have this problem using the default ROS wrapper on the Xavier and had to make modifications.
We are at risk of going over-budget due to the high cost of high power motors and controllers, and our custom frame. Our mitigation strategy is to look into prebuilt bases and potentially relaxing our requirements to allow for less powerful hardware.
We did calculations to determine our motor and battery requirements, but the calculations use some assumptions. We use a safety factor of 1.2, but in the case that this was not enough overhead, we would mitigate by relaxing our speed, weight, and battery duration requirements
Changes to System Design
Decided on depth cameras over lidar for vision due to budget constraints; we have an Intel RealSense already.
There is a risk that the WiFi on campus will not be consistent enough for our latency requirements. One contingency plan we have is to place a cellphone with a hotspot onboard the robot if the campus WiFi is not satisfactory. But this likely has implications for our ROS network since it would traditionally run in a local area network.
Another risk is that localization algorithms may not work on campus. A mitigation plan is to test building a map on campus using an Intel Realsense before ordering parts, so we can finalize the correct sensor modalities. Contingency plan is to use fiducial markers.
Changes to System Design
Changed our design from 2 motors per driver to 1 motor per driver based on feedback from Prof. Kim. Using multiple motors on a driver would make accounting for any minor differences between motors very difficult.
Decided on WiFi over LTE as our target for low-level communication protocol based on the suggestion from Prof. Kim that it is simpler to integrate into our robot.
