Skip to content

Commit 3a32f11

Browse files
authored
Merge pull request #5
Refactor Legacy Docs to Markdown
2 parents c9ab3a1 + 54e7811 commit 3a32f11

File tree

118 files changed

+973
-1613
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

118 files changed

+973
-1613
lines changed

app/(docs)/docs.css

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -11,20 +11,20 @@
1111

1212
html,
1313
body {
14-
max-width: 100vw;
15-
overflow-x: hidden;
14+
width: 100vw;
15+
overflow: hidden;
1616
padding: 0;
1717
margin: 0;
1818
font-size: 20px;
19-
min-height: 100vh;
19+
height: 100vh;
2020
}
2121

2222
main {
2323
width: 100%;
2424
padding: 0 15%;
2525
flex: 1;
2626
grid-area: main;
27-
height: 100svh;
27+
height: 100%;
2828
overflow-y: scroll;
2929
}
3030

File renamed without changes.
Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
====== How to Run a Pool Test ======
1+
# How to Run a Pool Test
22

33
Pool tests are probably the most important event that happen on a regular basis.
44
How your submarine performs at a pool test is roughly the same as how it will perform at competition.
@@ -7,17 +7,17 @@ It takes roughly 200 hours of in pool time to get into the finals. And roughly 5
77
Of course it's not enough to just put the sub in the pool. We need to have useful and relevant tests
88
in order to improve.
99

10-
===== Before the pool test =====
10+
## Before the pool test
1111
There is a lot of preparation that must be done before a pool test in order for it to be effective.
1212

13-
== The actual work to be tested must be done at least 2 days before the test ==
13+
##### The actual work to be tested must be done at least 2 days before the test
1414
This ensures that we will have enough time to fix any hiccups or cancel the test if need be.
1515

16-
== Create a pool test schedule ==
16+
##### Create a pool test schedule
1717
Simple timeline of "this will be tested at this time and for this long" for all the things we need to test.
1818
This ensures we don't burn a pool test wondering at one thing that went wrong and helps keep things moving.
1919

20-
== Schedule people to go to the pool test ==
20+
##### Schedule people to go to the pool test
2121
Pool tests are a chore especially since we usually have to schedule them on weekends.
2222
We want to avoid making the same set of people go to all the pool tests for a semester.
2323
Try to have a rotation so people don't get burned out.
@@ -26,12 +26,12 @@ Often our projects will end up in pool testing for a long time.
2626
It's expected that if your one person project is in testing you go to the pool test.
2727
That being said it's always better to have 2 or more people on a project.
2828

29-
== A dry test must be performed ==
29+
##### A dry test must be performed
3030
This makes sure that everything will go smoothly at the test itself.
3131
People will know what order they will run in and have a fresh memory of how to boot everything up.
3232
This also ensures that the code on the sub is all up to date and people have stuff able to run.
3333
Dry test is preferably at least a couple days before the pool test so you have some time to fix things
3434
if you run into any.
3535

36-
===== Test Day =====
37-
==TODO==
36+
## Test Day
37+
##### TODO
Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
1-
====== Home ======
1+
# Home
22

3-
===== Welcome to the Technical Documentation for Palouse RoboSub =====
3+
## Welcome to the Technical Documentation for Palouse RoboSub
44

55
Please place any write-access requests in the [[slack\>it|IT slack channel]]
66

7-
===== Main Pages: =====
7+
## Main Pages:
88
[[:cs:|Computer Science]] \\ /\<wrap indent\>Programming Documentation/\</wrap\>\\
99
[[:ee:|Electrical Engineering]] \\ /\<wrap indent\>Microcontroller and Wiring Documentation/\</wrap\>\\
1010
[[:me:|Mechanical Engineering]] \\ /\<wrap indent\>Hardware Documentation/\</wrap\>
Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,50 @@
1-
====== AI ======
1+
# AI
22
Main function of AI on the sub is to make decisions of what the sub should do based on given data from topics like sensors, vision, data, etc. It is using hierarchical state machine, which allows it to cover majority of cases it will face.
33

4-
===== Overview =====
4+
## Overview
55

6-
Current AI uses [[http://wiki.ros.org/smach | SMACH]] package that is in ROS. SMACH is a task-level architecture for rapidly creating complex robot behavior. At its core, SMACH is a ROS-independent Python library to build hierarchical state machines.
6+
Current AI uses [ SMACH](http://wiki.ros.org/smach ) package that is in ROS. SMACH is a task-level architecture for rapidly creating complex robot behavior. At its core, SMACH is a ROS-independent Python library to build hierarchical state machines.
77

88
Advantages of SMACH are:
99
- rapid development, ability to create complex state machines
1010
- ability to quickly change state machines without big code changes
1111
- explicitly define outcomes of every state thus covering most or all possible situations
12-
===== Current AI =====
12+
## Current AI
1313

1414
Our current AI was re-written using SMACH. There are several utility files such as:
1515
- gate_util.py - all states that are used by gate AI, they are generic.
1616
- util.py - contains utility functions for vision to filter labels, get N most probably, normalize coordinates from vision, or wrap yaw. **Note that vision will be changed in future, some of the functions will no longer be useful.**
1717
- basic_states.py - contains all of the states for roulette and dice AI.
1818
- control_wrapper.py - wrapper made to ease communication with control system, making it easy to send basic commands such as dive, yaw, pitch, roll, move forward.
1919
- start_switch.py - every high-level state machine **must** have start_switch as their first state. It is a state that waits for ros message to be sent over topic /start_switch to be true at least 3 times.
20-
- blind_movement.py - contains move_forward state that moves forward with //**x**// speed for //**y**// number of seconds.
20+
- blind_movement.py - contains move_forward state that moves forward with ***x*** speed for ***y*** number of seconds.
2121
- SubscribeState.py - a state that was made which accept also topic to which you want to subscribe. It is also modified to pass over any input/output keys. **In future this file will also contain SynchronousSubscribeState that subscribes to two topics and moves once it has two**
2222

23-
There is a useful tool to see state machine and transitions of it called [[http://wiki.ros.org/smach_viewer|smach_viewer]]. To run it, run
24-
\<code bash\>
23+
There is a useful tool to see state machine and transitions of it called [smach_viewer](http://wiki.ros.org/smach_viewer). To run it, run
24+
```bash
2525
rosrun smach_viewer smach_viewer.py
26-
\</code\>
26+
```
2727
An example of what our AI looks like in smach_viewer is this screenshot below
2828
`\{\{ :cs:ai:gate_ai.png?nolink |\}\}
29-
===== Things to know when developing AI =====
29+
## Things to know when developing AI
3030
* When inheriting from **SubscribeState** instead of **SmachState**, you need to use **self.exit("outcome")** instead of **return "outcome"**
3131
* Every python script that is going to run any state machine **must have** in its main function these lines of code below.
32-
\<code python\>
32+
```python
3333
while rospy.get_time() == 0:
3434
continue
35-
\</code\>
35+
```
3636
* Every time you create control_wrapper instance, you need to set depth value again.
3737
* If your state is using control wrapper to move, right before final outcome make sure to set changed yaw/roll/pitch/forward to 0.
3838
* Control wrapper forward and strafe do not use relative same way as yaw and pitch, use instead **strafeLeftError()** and **forwardError()**
3939
* Some current AI files use parameters from roscore server for different configuration of values. They will crash if they do not load parameters. Parameters are located in \<wrap em\>/ros/robosub/param/\</wrap\> or some may be located in individual utility folders. To load parameters run
40-
\<code bash\>
40+
```bash
4141
rosparam load [param_file_name].yaml
42-
\</code\>
42+
```
4343
* Every time you restart roscore you need to reload parameters
4444
* Our vision detection requires undistortion to be running.
4545

4646

47-
===== Example Flow Chart =====
47+
## Example Flow Chart
4848
\<flow\>
4949
graph LR;
5050
A(SM_ROOT)--\>|execute|B[START_SWITCH];
Lines changed: 18 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,45 +1,45 @@
1-
====== Cameras ======
1+
# Cameras
22

3-
===== Overview =====
3+
## Overview
44

5-
* The cameras that we use for the sub are Point Grey Flea3 GigE Vision ethernet cameras. Specs and downloads are available here. [[http://www.ptgrey.com/flea3-14-mp-color-gige-vision-sony-icx267-camera|Flea3]]
5+
* The cameras that we use for the sub are Point Grey Flea3 GigE Vision ethernet cameras. Specs and downloads are available here. [Flea3](http://www.ptgrey.com/flea3-14-mp-color-gige-vision-sony-icx267-camera)
66
* The cameras come with an SDK which contains configuration software and programmable interfaces for the camera. You can access it on their website.
77

8-
===== Datasheets =====
8+
## Datasheets
99
\{\{ :cs:cameras:basic_specs-flea3-gige.pdf |\}\} \\
1010
\{\{ :cs:cameras:fl3-ge-imaging-performance.pdf |\}\} \\
1111
\{\{ :cs:cameras:fl3-ge_gettingstarted.pdf |\}\} \\
1212
\{\{ :cs:cameras:flea3-ge-technical-reference.pdf |\}\}
1313

1414

15-
===== First Time Setup =====
15+
## First Time Setup
1616

1717
* Since the cameras are ethernet cameras the only thing you need for setup is an ethernet connection and a 12V power supply. The cameras take a few seconds to boot up and usually give themselves a default IP that is not on the network. You can use the flycap software to detect the cameras and add them to the network.
1818

19-
===== Configuration =====
19+
## Configuration
2020

2121
* Before you edit any camera settings, be sure to read the ENTIRE guide on the flycap configuration software as well as the IEEE-1394 camera standard. These documents give great insight into the design, terminology, and typical settings of the cameras.
2222
* Note, that the Flea3 cameras are somewhat tricky to configure correctly. Using factory settings, the cameras will most likely cause image inconsistency errors due to packet loss. Since most ethernet packet sizes are not suitable for streaming, it is almost necessary to increase packet size to jumbo (9000 bytes) in order to get the smoothest streaming possible.
2323
* On Windows this can be done in Network Devices by configuring the driver to have jumbo packets. In Linux this can be configured with: sudo ifconfig eth0 mtu 9000.
2424
* The packet delay should also be changed to account for the packet size increase. It should be the lowest delay that does not cause consistency errors depending on the setup. This can be tested by configuring the delay and running the cameras for about 5 minutes. If the cameras report no loss then those settings are optimal.
2525
* Be aware that the jumbo packet size cannot usually be maxed out. (On my system I could only get to ~7000 byte packets before the stream would freeze) In order to get optimal settings you have to play with the packet size and delay until you get the highest estimated bandwidth without errors.
2626

27-
===Serial Numbers===
27+
#### Serial Numbers
2828
* Left:
2929
* Right: 14406634
3030

31-
===== Camera Settings =====
31+
## Camera Settings
3232

3333
* The cameras can use multiple encodings depending on bandwidth and desired end types. For low bandwidth setups, Raw8 is the best encoding. You can configure post processing to convert the Raw8 into RGB8. Rigorous will return the best results. For medium bandwidth YUV422 returns great results, and for high bandwidth RGB8 is best as it requires no additional conversion once it reaches the computer.
3434
* Since the cameras use orthographical fisheye lenses, the best image would be a square centered on the image circle. Since the Flea3 only supports resolutions up to 1032p, the best image is 1032x1032 centered. (I guessed around 162px right)
3535
* Since conditions can change at the competition, it seems it is best to allow the cameras to auto adjust exposure, gain, and whitebalance. Although this makes the vision input somewhat unpredictable, you can stamp each frame with this information in the top left hand corner. The flycap SDK can save it once it reaches the computer if you want to analyze the footage later and figure out what settings the camera has at that point in time.
3636

37-
===== Problems / Fixes =====
37+
## Problems / Fixes
3838

3939
* PGR cameras have issues on linux with large packet types. In order to fix this the buffer needs to be increased.
4040

41-
===Linux Streaming Fix:===
42-
Derived from here: [[https://www.ptgrey.com/KB/10016|Linux Streaming Fix]]
41+
#### Linux Streaming Fix:
42+
Derived from here: [Linux Streaming Fix](https://www.ptgrey.com/KB/10016)
4343

4444
CAUSE:
4545
When streaming images from a GigE Vision camera on Linux Ubuntu 8.04 systems, a high number of lost data packets may be observed. In FlyCapture SDK applications, dropped packets result in IMAGE_CONSISTENCY_ERRORS returned.
@@ -54,17 +54,20 @@ Note: On some ARM boards, you may need to increase the receive buffer size to gr
5454

5555
The following sysctl command updates the receive buffer memory settings:
5656

57+
```bash
5758
sudo sysctl -w net.core.rmem_max=1048576 net.core.rmem_default=1048576
59+
```
5860

5961
Note: In order for these changes to persist after system reboots, the following lines must be manually added to the bottom of the /etc/sysctl.conf file:
6062

6163
net.core.rmem_max=1048576
6264
net.core.rmem_default=1048576
6365
Once changes are persisted, they can be reloaded at any time by running the following command in sysctl:
6466

67+
```bash
6568
sudo sysctl -p
66-
67-
==== Running With ROS ====
69+
```
70+
### Running With ROS
6871

6972
Point Grey supplies drivers for our Gig E cameras. You will need to have installed them:
7073

@@ -79,9 +82,9 @@ The cameras should begin publishing on the **/camera/[left|right|bottom]/image**
7982
roslaunch robosub cameras.launch left_serial:=12345678 right_serial:=12345679
8083
In the future, a downward facing camera is also planned to be added, though many of the steps will be similar.
8184

82-
One more note, when using the Point Grey drivers, the cameras will publish a [[https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg|WFOVImage]] message so many standard ros systems may not be able to use the data without it being republished. A republisher has been implemented in the Robosub repository and can be run with the following command:
85+
One more note, when using the Point Grey drivers, the cameras will publish a [WFOVImage](https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg) message so many standard ros systems may not be able to use the data without it being republished. A republisher has been implemented in the Robosub repository and can be run with the following command:
8386
rosrun robosub camera_repub
84-
This will republish the [[https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg|WFOVImage message]] messages as [[http://docs.ros.org/api/sensor_msgs/html/msg/Image.html|sensor_msgs/Image]] messages on the **/camera/[left|right|bottom]/undistorted** topic which aligns with the undistortion nodes so nodes are agnostic as to whether or not undistortion is being performed.
87+
This will republish the [WFOVImage message](https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg) messages as [sensor_msgs/Image](http://docs.ros.org/api/sensor_msgs/html/msg/Image.html) messages on the **/camera/[left|right|bottom]/undistorted** topic which aligns with the undistortion nodes so nodes are agnostic as to whether or not undistortion is being performed.
8588

8689

8790
\{\{bryant-koshu-mech-copy.jpg\}\}
Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,33 +1,33 @@
1-
====== Coding Conventions ======
1+
# Coding Conventions
22
Due to this being a collaborative software project among new developers, it's important to make sure that the code you write is clean and usable by others. We predominantly use two languages in this project, C++ and Python. Below are a list of coding conventions for each respective language in the project. There may be exceptions to these rules, but otherwise they should be followed. A code linter will be created to ensure that code conforms to there standards.
33

4-
====== roslint ======
4+
# roslint
55
To check if you code passes standard checks, compile using:
66
rsmake roslint
77
This will invoke the compiler with the code linter turned on. The C++ linter will run first and will fail with an error if the linter fails and the Python linter will not be run. If the C++ code passes the linter then the Python linter will be run.
8-
===== All Languages =====
9-
===Indentation===
8+
## All Languages
9+
#### Indentation
1010
Spaces shall be used for indentation, no tabs. \\
1111
**Rational:** mixing tabs and spaces can cause major bugs in Python, and can create ugly formatted code in all other languages, so consistency is important. Although I prefer all tabs in Python, spaces makes more sense for other languages.
12-
===Line Length===
12+
#### Line Length
1313
The maximum length of a line shall be 80 characters \\
1414
**Rational:** this results in code that is readable on most screens without wrapping lines
1515

16-
===Trailing Spaces===
16+
#### Trailing Spaces
1717
Trailing whitespace at the end of a line is not allowed. \\
1818
**Rational:** most text editors will actually automatically chop the trailing whitespace when you open a file. If people aren't paying attention, this can result in them commiting a file where they made no functional changes other than to cut the whitespace, resulting in a confusing source control history. In addition, it's just a cleanliness thing.
1919

20-
===Extra Newlines===
20+
#### Extra Newlines
2121
More than one blank line in a row is not allowed. \\
2222
**Rational**: If you need to break up your code into logical chunks it is better to use a single newline and a comment describing the next code block.
23-
===== C++ =====
23+
## C++
2424
running
2525
astyle -A1 -N -n \<file name\>
2626
on your C++ files should clean them up nicely.
27-
===== Python =====
27+
## Python
2828

2929
Nodes should be defined in classes with the constructor called in the "main" section.
30-
\<code python\>
30+
```python
3131
def Node():
3232
def __init__():
3333
# define pubs and subs here
@@ -37,4 +37,4 @@ if __name__=='__main__':
3737
rospy.init_node()
3838
Node()
3939
rospy.spin()
40-
\</code\>
40+
```

0 commit comments

Comments
 (0)