Working on connecting SNOOPI to the computer. Ran into many errors with IP addresses not matching, connection to ports being refused, SSH being restricted, and more. Thinking of downloading third-party firmware to assist with connecting. Currently trying to connect with offical firmware already on SNOOPI.
Links
ROS2 GitHub Download FOXY for CycloneDDS CycloneDDS Communication
Trying to download the ROS onto SNOOPI using various methods/GitHubs.
Links
Still having issues with connecting to SNOOPI. Currently going to try to download Python3 so we can use that for coding our programs. After some research it seems that we are using the wrong network interface. We were using eno2 from the YouTube video we saw, but our configuration is eno1. Tested that and still no change.
After talking with our Capstone Supervisors, we were given permissions to use the unofficial firmware. We are currently setting it up. Using Humble as our firmware; instructions from the link below. We were able to download Docker and CycloneDDS as the GitHub mentioned. Successfully downloaded the new firmware onto SNOOPI, but haven't tested it yet.
Links
Unofficial GitHub Humble Download
The new firmware focuses on Mapping and Environement Sensing. In terms of movement, it is only at a high-level code. Part of this new firmware, gives us a launch file that will open a UI that contains different LiDAR scan outputs, camera viewing, and more. However, when trying to connect to SNOOPI with the UI, there are many errors showing saying connection isn't working.
Finally got the computer to connect to SNOOPI. The issue was that the current IP address we were trying to use was for LAN0 on SNOOPI. There was no other IP address available, but on the Unitree App, when you connect to SNOOPI and run the Automatic Dectection, which is like a diagnostic check, within the log file, there was a differnt IP address for the Ethernet port. Changed the IP address on the computer to match SNOOPI's and the UI connected to SNOOPI and started showing live view from the LiDAR and camera. Now we are testing sample code to make sure we can run different programs. Created 2 files for testing, one for LiDAR scans and one for movment. LiDAR will returns values for closest objects and movement will just move SNOOPI at different speeds for different durations.
Worked on documentation. Added more comments to the current python files.
Got the LiDAR scan code to work. We are now retrieving values form the scan and we have the print statements to tell us the closest value's distance. However, the values don't seem to be accurate. When physically measuring the distance of an object, it can be off by about 0.05m to 0.10m from the reading in the code.
Trying to connect to SNOOPI over Wi-Fi instead of Ethernet for furture testing and presenting. Connection does work and we can run programs, but it seems to disconnect multiple times so we would have to restart the connection from the terminal. Not difficult but can be annoying. LiDAR scans still give incorrect values.
Seems like the LiDAR scans are more accurate when SNOOPI's head a bit tilted downwards. Trying to see if we have control over specific joints so we can make SNOOPI bow down a bit so get more accurate values. Seems like the parameters we have access to in this firmware is only high-level movement so we don't have access to joints. We found a built in parameter called 'Obstacle_Detection'. Implementing that into the movement code so we can turn the parameter on, run our code, and turn the parameter off. Obstacle detection is more accurate now. Did a test case where SNOOPI would work forward and someone would jump right in front of SNOOPI and see how quikcly it can stop. Test case was successful! SNOOPI immediately stopped with no isses. Will be using this parameter for obstacle detecting in movement, but will still use the LiDAR class for obstacle detection.
Since the Obstacle_Detection parameter is built-in, we can't seem to find how to modify its configuration. The range for the paremeter seems to be abuot 0.5m but we don't know if we can change it or not. Created a new file called "walk_path.py" that is meant to walk a path on its own and have its own decision making. It's intial test will be to walk around the lab and see if it can turn when there is an obstacle.
Continued to work on the "walk_path.py" file. Turns are not that accurate.
Continued to work on the "walk_path.py" file. Decision making on when to turn left or right isn't accurate. There would be many times it would get stuck on an infinite spin.
Continued to work on the "walk_path.py" file. Changed the decision making for now so instead of deciding to turn left or right, it will always spin counter-clockwise until it detects a path with no obstacle, in which case it will continue. Removed the duration of the code to an infinite run-time until the User sends a KeyBoard Interrupt. Had one successful test where SNOOPI completed about 80% of the path around the room before getting stuck. Still need to improve its scan accuracy as sometimes it prints "No valid readings" when facing an obstacle.
Continued to work on the "walk_path.py" file. Testing different angle readings as the front values. Unsure if the front center is 180 deg or not. Keyboard Interrupts make it stop, but the full_stop() that is supposedly runs doesn't run the way it should. Thinking about changing the LaserScan to PointCloud, will require more effort, but can possible change the obstacle detection accuracy"
Continued on "walk_path.py" file and also made a new file called "movement.py" under a new folder called "core_modules". The new folder is used for the final modules we want to implement onto SNOOPI while the sample_scripts is used for testing classes, functions, and certain tests. Tried to implement PointCloud2 for a 3D LiDAR but the data seems harder to understand and store into variables corectly for proper use. Issue we were having is that the closest distance output would be the same repeating number regardless where the actual object is, even if the actual object is closer than the closest object printed. Going to continue to use LaserScan. Tried to modify the obstacle detection decision making by having it take a set of the smallest values it reads and take the average of that to remove any false positives.
Got LiDAR to use Point Cloud instead of LaserScan and the values seem to be reading better. Updated the movement.py file to use Point Cloud instead of Laser Scan and it produces better results. LaserScan used indices for 360 degrees for distance. Point Cloud uses (x,y,z) values but no store indices so will need to use the y and z axis to create a scope for viewing. Trying to use atan2 and +- values for y but it doesn't seem to be even (right side picks up objects closer to the body of the bot instead of the head, and the left side struggles to find a close object).
Working on horizontal range for sensing obstacles. Currently it can make decisive turns on which side an obstacle is and which side to turn, however its not the most accurate. Need to find a better angle for the horizontal range to get more accurate results. Reading documentation on creating a UI. Thinking about using Web UI which includes HTML, CSS, and Javascript/JQuery. With this implementation, converting it into an app shouldn't be too difficult.
Figured out how to pull the accurate values from the LiDAR sensor. Using these values, the turning decisions were updated. Implemented a state machine into the code to confirm all the movement states before moving SNOOPI. Installing Flask as our user interface we want to use for inputting parameters. Flask creates a webserver to allow connection. Currently testing out 2 buttons for Start and Stop the current python movement program we have. Run the UI on a new terminal, instructions in the main user_interface.py file. With this open, the HTML now loads and can write the button presses to SNOOPI's program. The Status is read from SNOOPI. In SNOOPI's program, it is now a step function. Before it would be a while loop until a KeyBoard Interrupt but now that it reads the button, if the Stop button isn't pressed then the step function for movement will run indefinitely.
Attempted to use the webrtc_adapter class from filepath go2_robot_sdk/infrastructure/webrtc to send a command for the robot to sit down. Created a new function called sit_down() using async to allow for the connection to wait. Code was able to compile, however a solid connection seemed to be unable to be established with the robot itself so that a command could be executed. I think if we can figure out how to use webrtc_adapter and go2_connection we should use those to push commands going forwards as they seem to be more robust than publishing messages and may allow for us to code more complex and quicker actions comapred to publishing a message.
Tried a few different methods for connecting to SNOOPI in order to use laying down commands. Token and other parameters may need to be determined before a successful connection can be mdae, or aiortc may need to be installed. Will try a few other things first before installing any more packages.
Worked a bit over the holidays to modify some code for improving the obstacle avoidance and working on having SNOOPI sit and lay down. Created a batch file to do all the source and robot IP setup along with RVIZ before running any code.
Changed the continuous turning to incremental. Everytime there is an obstacle it does about a 30 degree turn in the appropriate direction and check again if there is an obstacle or if it can continue to move forward. Trying to get battery level information.
Got sit and stand commands to work. Working on trying to retrieve internal information like battery and internal temperature. Curerntly trying to implement nav2 has path planning. nav2 acts like a bridge that will connect the environment scan from SLAM to the joint information to move around and avoid obstacles.
Worked on Nav2 and path planning. Seems a bit better but not perfect, can still run into obstacles. Setting a goal is not that accurate and sometimes it does update relatively, but thinks the goal is asbolute every run. Also did research on external hardware implementation such as using the XT30 port for connecting a Raspberry Pi throuigh a buck converter. The Pi will connect to 2 UWB sensors used for tracking.