Auto-merge from CI

Author: madhephaestus

.github/workflows/publish.yml

@@ -10,8 +10,6 @@ name: Build and Deploy
 on:
   push:
     branches: [ source ]
-  pull_request:
-    branches: [ source ]
 
 jobs:
   website-deploy:
@@ -23,54 +21,10 @@ jobs:
 
     steps:         
     - uses: actions/checkout@v2
-    - name: Fetch
-      run: git fetch origin
-      
-    - name: Config
-      run: |
-            git checkout source 
-            git log -1
-            git config user.email "mad.hephaestus@gmail.com"
-            git config user.name "Kevin Harrington"
-            git config pull.rebase false
-            git config core.mergeoptions --no-edit
-            
-            
-    - name: Check deploy commit
-      run: |
-            git checkout deploy 
-            git log -1
-            git checkout source   
-      
-    - name: Merge deploy into source
-      run: |
-            git update-index --assume-unchanged ./.github/workflows/publish.yml
-            git merge origin/deploy --strategy-option ours --no-ff --no-edit --allow-unrelated-histories -m "Auto-merge from CI " 
-      
-      
-    - name: Checkout Deploy
-      run: git checkout deploy
-      
-    - name: Pull latest deploy
-      run: git pull
-      
-    - name: Pull changes in source into deploy
-      run: git pull origin source --allow-unrelated-histories
-      
     - name: Set up Ruby
-    # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby,
-    # change this to (see https://github.com/ruby/setup-ruby#versioning):
-    # uses: ruby/setup-ruby@v1
       uses: ruby/setup-ruby@473e4d8fe5dd94ee328fdfca9f8c9c7afc9dae5e
       with:
         ruby-version: ${{ matrix.ruby-version }}
         bundler-cache: true # runs 'bundle install' and caches installed gems automatically
-    - name: Deps For tests
-      run: bundle install
-   
-         
-    - name: Build Site
-      run: bundle exec rake site:deploy
-      
     - name: Push
-      run: git push --quiet 
+      run: bash deploy.sh

README.md

@@ -7,7 +7,7 @@ http://CommonWealthRobotics.github.io/
 
 Build monitor:
 
-https://travis-ci.org/CommonWealthRobotics/CommonWealthRobotics.github.io
+https://github.com/CommonWealthRobotics/CommonWealthRobotics.github.io/actions
 
 ## How this thing works ##
 * The content directory will become the root of the website.
@@ -24,11 +24,7 @@ see this link for updating .congif.yaml with a new token. https://gist.github.co
 ## Local Compile ##
 ```
   git clone https://github.com/CommonWealthRobotics/CommonWealthRobotics.github.io.git
-  sudo apt install rbenv
-  rbenv install 2.7.5
-  cd into CommonWealthRobotics.github.io
-  bundle install
-  bundle exec nanoc view & bundle exec guard
+  bash launch.sh
   
   For mac:
   Install xcode

Rakefile

@@ -213,10 +213,6 @@ namespace :site do
     # Commit and push to github
     sha = `git log`.match(/[a-z0-9]{40}/)[0]
     Dir.chdir(CONFIG["destination"]) do
-      sh "git config --global user.email 'mad.hephaestus@gmail.com'"
-      sh "git config --global user.name 'Kevin Harrington'"
-      sh "git add --all ."
-      sh "git commit -m 'Updating to #{USERNAME}/#{REPO}@#{sha}.'"
       puts "Pushed updated branch #{DESTINATION_BRANCH} to GitHub Pages"
       puts "My work is done, Will I Dream...?"
     end

Rules

@@ -23,7 +23,6 @@ compile '*' do
   elsif item[:extension] == 'js'
     # don’t filter stylesheets
   elsif item[:extension] == 'md'
-    filter :kramdown
     if item[:layout] != nil
         #puts "[#{Rainbow(item.reference).red}]\t\t layout '#{Rainbow(item[:layout]).yellow}' requested in front matter"
         layout item[:layout]

content/wAlnut/Introduction.md

@@ -0,0 +1,38 @@
+#!/bin/bash
+
+git fetch origin
+
+git log -1
+git config user.email "mad.hephaestus@gmail.com"
+git config user.name "Kevin Harrington"
+git config pull.rebase false
+git config core.mergeoptions --no-edit
+
+git checkout source   
+
+git update-index --assume-unchanged ./.github/workflows/publish.yml
+git merge origin/deploy --strategy-option ours --no-ff --no-edit --allow-unrelated-histories -m "Auto-merge from CI " 
+
+git checkout deploy
+
+git pull --allow-unrelated-histories
+
+git merge source --strategy-option ours --no-ff --no-edit --allow-unrelated-histories -m "Auto-merge from CI " 
+
+git pull . source --allow-unrelated-histories
+
+set -e 
+
+bundle install
+
+bundle exec rake site:deploy
+
+set +e
+
+git add --all .
+
+git commit -a -m"Update for deploy"
+
+git push origin deploy 
+
+git checkout source

content/wAlnut/index.md

@@ -131,24 +131,30 @@
         <div class="col-sm-9" role="main">
             <div class="bs-docs-section">
 
-<h2 id="jacobian">Jacobian</h2>
 
-<p>For Kinematic systems, the Task Space is used to describe the global coordinates, where the task is being performed.  Forward Kinematics solves for the Task Space based on the robot properties.  The Joint Space is the internal robot reference system, which typically includes the joint angles, lengths and offsets.  Inverse Kinematics solves for the Joint Space from the Task Space.  Both are important ways of modeling jobs and systems, and being able to convert between them are absolutely critical in modeling and job functionality.</p>
+##Jacobian
 
-<p>A Jacobian Matrix defines the physical properties and is used in both Forward and Inverse Kinematics models to translate between the Task and Joint spaces.  The Jacobian matrix, which is calculated from the DH parameters and current pose of the system, multiplied by the Joint Space Velocity matrix gives the Task Space Velocity.  The Inverse Kinematics side can get much more complicated as adjusting this equation to solve for the Joint space means taking the inverse of the Jacobian matrix.</p>
+For Kinematic systems, the Task Space is used to describe the global coordinates, where the task is being performed.  Forward Kinematics solves for the Task Space based on the robot properties.  The Joint Space is the internal robot reference system, which typically includes the joint angles, lengths and offsets.  Inverse Kinematics solves for the Joint Space from the Task Space.  Both are important ways of modeling jobs and systems, and being able to convert between them are absolutely critical in modeling and job functionality.
 
-<h2 id="inverse-jacobian">Inverse Jacobian</h2>
+A Jacobian Matrix defines the physical properties and is used in both Forward and Inverse Kinematics models to translate between the Task and Joint spaces.  The Jacobian matrix, which is calculated from the DH parameters and current pose of the system, multiplied by the Joint Space Velocity matrix gives the Task Space Velocity.  The Inverse Kinematics side can get much more complicated as adjusting this equation to solve for the Joint space means taking the inverse of the Jacobian matrix.
 
-<p>By definition, the inverse of a matrix is what needs to be multiplied by a matrix to result in the identity matrix.  Only square matrices can have inverses, and not all square matrices can be inverted (and are called noninvertible or singular).  In kinematics, the Jacobian matrix size is based on both the number of links and degrees of freedom.  The three possible conditions are where the system DOF and the number of links are: equal, greater than or less than.  There will only be a square Jacobian when the system DOF and number of links are equal.  When the system DOF is greater than the number of links, it is very possible that not all desired states are achievable.  When the number of links is greater than the system DOF, over-articulation is possible.  This means that there may be multiple poses that give a solution to one particular task space.  A 6 link system in a 3 DOF space (x,y,z coordinates) will result in a Jacobian with 3 rows and 6 columns.</p>
+##Inverse Jacobian
+
+By definition, the inverse of a matrix is what needs to be multiplied by a matrix to result in the identity matrix.  Only square matrices can have inverses, and not all square matrices can be inverted (and are called noninvertible or singular).  In kinematics, the Jacobian matrix size is based on both the number of links and degrees of freedom.  The three possible conditions are where the system DOF and the number of links are: equal, greater than or less than.  There will only be a square Jacobian when the system DOF and number of links are equal.  When the system DOF is greater than the number of links, it is very possible that not all desired states are achievable.  When the number of links is greater than the system DOF, over-articulation is possible.  This means that there may be multiple poses that give a solution to one particular task space.  A 6 link system in a 3 DOF space (x,y,z coordinates) will result in a Jacobian with 3 rows and 6 columns.
 
 <script src="https://gist.github.com/mdiblasi/9925fd3572b30419c425.js"></script>
 
-<h2 id="pseudo-jacobian">Pseudo Jacobian</h2>
+##Pseudo Jacobian
 
-<p>Generating the Inverse Jacobian for solving the Inverse Kinematics (assuming achievable poses), isn’t possible for non-square Jacobians.  In these cases, which are typically iterative rather than analytic, an approximation is appropriate, which is achieved with the Pseudo Jacobian.  The Pseudo Jacobian is calculated by manipulating the Jacobian, which has the extra benefit of avoiding a case where two sequential limbs are locked straight out, also known as a singularity condition.</p>
+Generating the Inverse Jacobian for solving the Inverse Kinematics (assuming achievable poses), isn't possible for non-square Jacobians.  In these cases, which are typically iterative rather than analytic, an approximation is appropriate, which is achieved with the Pseudo Jacobian.  The Pseudo Jacobian is calculated by manipulating the Jacobian, which has the extra benefit of avoiding a case where two sequential limbs are locked straight out, also known as a singularity condition.
 
 <script src="https://gist.github.com/mdiblasi/38c718158daeb0dda564.js"></script>
 
+
+
+
+
+
 
             </div>
         </div>

deploy.sh

@@ -131,14 +131,13 @@
         <div class="col-sm-9" role="main">
             <div class="bs-docs-section">
 
-<h2 id="analytic-solver-overview">Analytic Solver Overview</h2>
+##Analytic Solver Overview
 
-<p>Simple robot systems can be analytically solved when constraints and degrees of freedom align.  Delta robots and 2 link revolute (rotational joint) arms are two examples of such robots that can be analytically analyzed.  A delta robot is a system with 3 identical towers or points of rotation, all connecting to one tool tip.  Depending on the configuration, it can pivot around a point or traverse the space, mirrored in 120 degree segments around the work space.  This is also a great example of Parallel links, whereas a Series system, (like the 2 link revolute arm) is a series of sequential links connected one by one.  There is one pose per achievable position since they aren’t over-constrained.  It may not be possible to fully orient in every position, but mapping forward and inverse kinematics is a direct affair.</p>
+Simple robot systems can be analytically solved when constraints and degrees of freedom align.  Delta robots and 2 link revolute (rotational joint) arms are two examples of such robots that can be analytically analyzed.  A delta robot is a system with 3 identical towers or points of rotation, all connecting to one tool tip.  Depending on the configuration, it can pivot around a point or traverse the space, mirrored in 120 degree segments around the work space.  This is also a great example of Parallel links, whereas a Series system, (like the 2 link revolute arm) is a series of sequential links connected one by one.  There is one pose per achievable position since they aren't over-constrained.  It may not be possible to fully orient in every position, but mapping forward and inverse kinematics is a direct affair.
 
-<h2 id="analytic-solver-techniques">Analytic Solver Techniques</h2>
+##Analytic Solver Techniques
 
-<p>Direct systems can be analyzed as a series of linear equations or simplified to laws of triangles.  A 2 link planar arm reaching for a point in 2D space has a limited number of ways to solve the end point.  The base position and end point are known, so the end position of link 1 is the unknown.  Drawing out the system to find that link position and with that the associated angles means equations of motion can be determined with a few simple lines of code or lower level math.  There is no standard algorithm for finding the ideal pose, and it does not need to be recursively run for optimization purposes.</p>
- 
+Direct systems can be analyzed as a series of linear equations or simplified to laws of triangles.  A 2 link planar arm reaching for a point in 2D space has a limited number of ways to solve the end point.  The base position and end point are known, so the end position of link 1 is the unknown.  Drawing out the system to find that link position and with that the associated angles means equations of motion can be determined with a few simple lines of code or lower level math.  There is no standard algorithm for finding the ideal pose, and it does not need to be recursively run for optimization purposes. 
             </div>
         </div>
     </div> <!-- row -->

docs/Bowler-Kinematics/Advanced_Kinematics/index.html

@@ -131,12 +131,11 @@
         <div class="col-sm-9" role="main">
             <div class="bs-docs-section">
 
-<h2 id="cad-scripts">CAD Scripts</h2>
+##CAD Scripts
 
-<p>Simulating is great for prototyping, finding issues and tweaking the design before much time or materials are invested.  The next logical step is hardware, which is accomplished in Bowler Studio through the use of CAD Scripts.  Once the design and function are sufficient, exporting to CAD for 3D printing, machining or other rapid prototyping methods is a simple button press away.  Installing standard servos and connections couldn’t be simpler, allowing for robots to go through the entire design process up to initial build quicker than ever before!</p>
+Simulating is great for prototyping, finding issues and tweaking the design before much time or materials are invested.  The next logical step is hardware, which is accomplished in Bowler Studio through the use of CAD Scripts.  Once the design and function are sufficient, exporting to CAD for 3D printing, machining or other rapid prototyping methods is a simple button press away.  Installing standard servos and connections couldn't be simpler, allowing for robots to go through the entire design process up to initial build quicker than ever before!
 
-<p>Allowing a designer to concentrate fully on function rather than form or compatibility allows for a richer design experience, as well as lowered development time.  Robot arms, walkers or mobile robot platforms can be great productivity (or educational) tools and with the capability to have the non-function design work automated more advanced systems are possible faster than one can be ordered.  Full system approaches like Bowler Studio lower the bar for manufacturing and learning yet raise the standard on robot design.</p>
- 
+Allowing a designer to concentrate fully on function rather than form or compatibility allows for a richer design experience, as well as lowered development time.  Robot arms, walkers or mobile robot platforms can be great productivity (or educational) tools and with the capability to have the non-function design work automated more advanced systems are possible faster than one can be ordered.  Full system approaches like Bowler Studio lower the bar for manufacturing and learning yet raise the standard on robot design. 
             </div>
         </div>
     </div> <!-- row -->