hugofara / pylinkage Goto Github PK

Several file format to save data are present and loosely defined. For now using a consistent JSON seems to be a better solution.

User like Pylinkage because it is easy to use. A nice GUI could be a plus. I'm thinking of similar projects like KmolYuan/Pyslvs-UI.

On the other hand that is a lot of work for the developer, and not so useful as it's a Python project, users have to code anyway. Maybe a controlled environment (as a web page), unrelated to this project is better.

Main reasons for this change:

• I prefer reST.
• reST seems to be the most popular format
  • Default pyment output
  • Default format for PyCharm
  • No additional required for Sphinx

Several reasons for this change suggestion:

* [PySwarms](https://github.com/ljvmiranda921/pyswarms) is no longer maintained

* The [genetic algorithm](https://en.wikipedia.org/wiki/Genetic_algorithm) is home-made

* [scikit-opt](https://github.com/guofei9987/scikit-opt) is complete (6 proposed meta-heuristics) and popular (more than 4k star )

Should not be too hard to do.

Originally posted in HugoFara/leggedsnake#4 .

Current standard use case for the library:

• The user imports pylinkage
• It defines a linkage of its liking
• Views the linkage with a function
• Defines any score function
• Somehow optimize everything?
• View the result again? What linkage?

If you change any parameter, the workflow is likely to be ran again. This is a tedious process.

What I'm thinking of:

• The user imports pylinkage in a linkage.py file.
• This file contains at least three functions:
  • define_linkage(dimensions, init_position) -> Linkage
  • optimize_linkage(dimensions, init_position) -> score
• With that we create the entry points "pylinkage-gui" and "pylinkage".
  • To view a linkage pylinkage-gui linkage.py
  • To optimize pylinkage linkage.py.

I strongly advice again using OOP on front-end as it will be confusing for users. On the back-end side that may be a good option.

The project relies on Euclidean geometry, and the code is home-made in pure Python. I think I can make it faster, with some caveats:

• We are always in 2D space, so general libraries such as NumPy are in fact slower to solve our issue (they allocate too much memory).
• Bigger Euclidean geometry library such as geometer are better than Numpy, but still slow (still N dimensional)
• Analytical libraries as SymPy are unpractical. They perform better with the paradigm "run once, get data".
• I want to give a try to shapely. It is a Python wrapper for a GEOS (C/C++), only in the Cartesian space.
• I'm open to suggestions!

Hi! Thanks for the library, it seems quite useful. Unfortunately I haven't been able to get even the simplest example to run succesfully. I tried using versions 0.5.3 and 0.5.2 and they both produce the same results:

import pylinkage as pl

# Main motor
crank = pl.Crank(0, 1, joint0=(0, 0), angle=.31, distance=1)
# Close the loop
pin = pl.Pivot(
    3, 2, joint0=crank, joint1=(3, 0),
    distance0=3, distance1=1
)

my_linkage = pl.Linkage(joints=(crank, pin))

locus = my_linkage.step()

crank.name = "B"
pin.name = "C"
# Linkage can also have names
my_linkage.name = "Four-bar linkage"

pl.show_linkage(my_linkage)

---------------------------------------------------------------------------
HypostaticError                           Traceback (most recent call last)
Input In [4], in <cell line: 20>()
     17 # Linkage can also have names
     18 my_linkage.name = "Four-bar linkage"
---> 20 pl.show_linkage(my_linkage)

File ~/venv/lib/python3.10/site-packages/pylinkage/visualizer.py:263, in show_linkage(linkage, save, prev, loci, points, iteration_factor, title, duration, fps)
    229 """
    230 Display results as an animated drawing.
    231 
   (...)
    260 
    261 """
    262 # Define intial positions
--> 263 linkage.rebuild(prev)
    264 if loci is None:
    265     loci = tuple(
    266         tuple(i) for i in linkage.step(
    267             iterations=points * iteration_factor,
    268             dt=1 / iteration_factor
    269         )
    270     )

File ~/venv/lib/python3.10/site-packages/pylinkage/linkage.py:495, in Linkage.rebuild(self, pos)
    483 """
    484 Redefine linkage joints and given initial positions to joints.
    485 
   (...)
    492     constraints.
    493 """
    494 if not hasattr(self, '_solve_order'):
--> 495     self.__find_solving_order__()
    497 # Links parenting in descending order solely.
    498 # Parents joint do not have children.
    499 if pos is not None:
    500     # Definition of initial coordinates

File ~/venv/lib/python3.10/site-packages/pylinkage/linkage.py:474, in Linkage.__find_solving_order__(self)
    472                 solved_in_pass = True
    473 if len(solvable) < len(self.joints):
--> 474     raise HypostaticError(
    475         'Unable to determine automatic order!'
    476         'Those joints are left unsolved:'
    477         ','.join(str(j) for j in self.joints if j not in solvable)
    478     )
    479 self._solve_order = tuple(solvable)
    480 return self._solve_order

HypostaticError: The system is hypo-static!

I'm on Linux, NixOS, kernel version 6.1.36, and using Python 3.10.

Any idea what could be causing this?

Hi. I want to create a linkage based on a four bar linkage but with extra linkages at the coupler, like a triangle pr a square. Those would not move. I thought about making the head triangle or square with Fixed joints but I get unsupoted operant type errors.

TypeError: unsupported operand type(s) for +: 'NoneType' and 'float'

How can I make a four bar linkage with extra unpowered links held by the coupler link?

I tried this code but the head still moves even tho the second crank should not move since the angle is 0

# Main motor
crank = pl.Crank(0, 1, joint0=(0, 0), angle=.31, distance=1, name="B")
# Close the loop
pin = pl.Pivot(3, 2, joint0=crank, joint1=(3, 0),
               distance0=3, distance1=1, name="C")

crank2 = pl.Crank(0, 2.5, joint0=crank, angle=0.0, distance=1.5, name="B2")
pin2 = pl.Pivot(3, 3, joint0=crank2, joint1=pin,
                distance0=3, distance1=1.5, name="C2")
fix = pl.Fixed(joint0=crank2, joint1=pin)
# Linkage definition
my_linkage = pl.Linkage(
    joints=(crank, pin, crank2, pin2),
    order=(crank, pin, crank2, pin2),
    name="My four-bar linkage"
)

# Visualization
pl.show_linkage(my_linkage)

Except from the direct use of the module, many users may want to adapt objects defined here. Allowing them to follow the SOLID principles would be nice. Hence, metaclasses.

Currently during the PSO optimization, a linkage is represented as a tuple : (score, dimensions, initial positions).

Using indexes every where does not make things easy to debug and prevents the development of more advanced features.

Using a named tuple should be enough here, but with extensions in mind an object would be better.

Radar plot was fun to implement, and started with the idea that some parameters live in different dimensions, plotting lines between them (using a standard plot) would confuse the user. In fact, radar plot is hard to read, and difficult to work with. A standard line plot may be better.

A nice mechanism library is gabemorris12/mechanism. Its provides many feature missing here, as it is intended for further mechanical analysis. Without copying it's content, here are three nice feature that can be added to pylinkage:

• Simple Chebychev–Grübler–Kutzbach criterion (already in pylinkage, but a simpler re implementation is better)
• Cam/Gear definition: I did not think about it, and it would be very nice to have it.
• Individual position/speed/acceleration for joints. Nothing hard here, but an implementation out-of-the-box would be great.

Using an crank with a negative rotation would prevent this method to work. freq = round(tau / j.angle) should be replaced by freq = round(tau / abs(j.angle)).

For now users can defined and angle above pi to solve this issue (instead of using an angle of -0.1, use 2*pi-0.1).

"Pivot joint" is not standard for most English speaker (not in the field or mechanics).