echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --dport 1111 -j DNAT --to-destination 10.8.0.8:22
DESIGN
Prototype
Our robotic dog had four legs, each of which was equipped with three servos: one for the shoulder, one for the upper part of the leg, and one for the lower part of the leg. Therefore, we made use of 12 servos in total. Most of the robot was 3D designed and 3D printed from scratch. We also used a servo controller with 16 channels to drive our servos. Our circuit also included a 2S Lipo battery and a 5V 20Amp BEC. Below are the electrical schematic and the 3D designs of our robot.
Walking Algorithm
In order to control the servos, we used the Adafruit PCA9685 PWM Servo Library, which was compatible with our servo controller. We assigned each servo to the following channels on the PCA9685 board:
- Channel 0: Back Lower Left Servo
- Channel 1: Back Lower Right Servo
- Channel 2: Back Shoulder Left Servo
- Channel 3: Back Shoulder Right Servo
- Channel 4: Back Upper Left Servo
- Channel 5: Back Upper Right Servo
- Channel 6: BEC Power +5.5V
- Channel 7: NC
- Channel 8: NC
- Channel 9: BEC Power +5.5V
- Channel 10: Front Upper Right Servo
- Channel 11: Front Upper Left Servo
- Channel 12: Front Shoulder Right Servo
- Channel 13: Front Shoulder Left Servo
- Channel 14: Front Lower Left Servo
- Channel 15: Front Lower Right Servo
The library allowed us to adjust the angles (0-180 degrees) of the servos. Through trial and error, we managed to come up with the appropriate angles of the servos for a neutral standing position. For the other configurations, we encoded them not as the angles but as the offsets from the neutral position, which means that if we added the offset arrays to the configuration of the array for the neutral position element by element, we would get the actual angle arrays of those configurations. Our reason for encoding the configurations this way was because if any of the servos ended up breaking, we would only need to change the offset configuration of that servo specifically.
We also made a function to change the robot angle that took in the arguments of the offset array, the neutral position configuration array, and the number of steps we wanted the servo to make. We then calculated the appropriate increments associated with each servo depending on the number of steps. We then continually incremented the servo’s angles using the calculated increments until it achieved the configurations that we wanted.
We got inspiration from watching several Youtube videos of robotic dogs and came up with a walking algorithm for going forward, turning left, turning right, and going backwards.
In our walking algorithm we utilized the shoulders in addition to the upper and lower legs in order to let the robot lift its leg off the ground to some extent while bringing its legs forward. This had the effect of letting the robots bring its legs forward without imparting a backwards force on the robot. This allowed the robot to move forward instead of wobbling in place like we have seen in previous tests. For walking order, we chose to alternate between diagonal legs (i.e. the front-left and back-right leg come forward, while the front-right and back-left leg go back, and vice versa). We found that this pattern of movement seemed to be the most stable of all the walking algorithms we tried. The pictured animation below shows how the robot would walk forward.
Backing up was accomplished by implementing a similar pattern to forward, however the animation would be reflected over the vertical axis. Turning left and right was accomplished by implementing the forward algorithm on the legs on one side of the robot and the backward algorithm on the other legs.
User Interface Components
In order to implement our web server, we made use of the Flask library, which was a lightweight WSGI web application framework. We implemented a very basic website that had links that sent GET requests to different endpoints in the server. Each endpoint called a corresponding function for robot movement (i.e. the endpoint for forward would simply call our forward function and the forward function would handle all the servo manipulations).
As for our GUI display on the PiTFT, we used the Pygame library to implement the feature. For the history display, we made use of a double ended queue of 5 elements. We implemented a panic stop button that, if pressed, would make the robot stop moving and continue with its movement after the resume button was pressed. We also implemented a quit button that helped quit the program if pressed.
Below is a high-level software/network architecture overview of our project:
On boot up the raspberry pi automatically connects to an openvpn server running on a very cheap Linode VPS (price negligible). This VPS has a public IP address which the domain name jo3.cc points to. In order to make the raspberry pi’s services (ssh, webcam, web server) accessible to the public internet, port forwarding from the VPS was used via the Linux iptables tool. For example, since the vpn assigns the pi a static private ip of 10.8.0.8, we can execute these commands on the VPS to tell it to forward incoming requests on jo3.cc port 1111 to the raspberry pi’s ssh port (22):
This way, on the public internet the pi could be accessed by doing:
ssh pi@jo3.cc -p 1111
In order to integrate a live feed web camera into our website we used motion-project webcam software and configured it in order for the pi to make a camera feed available on port 8081 on boot up. The flask web server / python program would then be on port 5000 and the website it serves up would make the client send a request to port 8081 to pull down the live feed. Ports 8081 and 5000 were exposed to the public in a similar fashion to port 1111.
