Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Newb perspective
spiked3
Member Posts: 34 ✭
I can tell most of you are seasoned pros. I am coming from this as a very ammeture, having used Alibre, not Solidworks. I would have to say this is the first software I have been excited about in a long time. I really hope you start a second division and do the same with E-CAD, it needs it badly.
That said, here are some notes I jotted down first day;
That said, here are some notes I jotted down first day;
assembly; when I paste a part, if I am hovering mate connector, an attempt should be made to solve it, or at least as much of it as possible
sketch; Shift and shortcut should cycle multi tools, ie 'r' selects rectangle, shift-r changes it to centered rectangle. You can limit this so it does not interfere with other uses of shift. ie 'shift-r' only has this affect immediately after 'r'
help; file doesnt match actual for short cut r=parallel not rectangle 3/4/15
No way to re-order features? for example I created a sketch on the wrong face. I added a plane with the correct offset, but I could not place it before the sketch so I could move the sketch to it. I would think some features would be movable, like plane.
sketch; really needs a construction toggle
sketch; really needs pattern but I believe I saw that is already in the plans
UX; I used history for the first time, and it was not obvious how to get out. a popup similar to others would probably be better
UX; clipboard-cut seems like it should be there, but I suppose it is not necessary
Bug/Sketch; seems like I sometimes get a centered rectangle when the toolbar icon is not centered rectangle. first time I ignored it, but it has happened since, so maybe I'm hitting a shortcut I do not know about?
Mike Partain aka Spiked3
http://www.spiked3.com
http://www.spiked3.com
0
This discussion has been closed.
Comments
There are 2 ways to toggle to construction:theres an icon that let's you do it, and then you can select items then rmb and pick construction (preferred method).
What's different is the contour select feature after the sketch has been created. Sketch must be shown and you pick regions of the sketch when you are extruding/whatever. Because of this, you don't have to use construction geometry as before. It's almost difficult to pick the sketch like other CAD default to and I pick the sketch from the feature tree to accomplish the "extrude sketch" behavior. I mention this because the use of construction geometry is less significant if you can choose regions from a sketch. These region select methods don't seem as robust as sketch select, they seem to cause failures more often as geometry changes, could be me. This is a new use pattern that I'm trying to master and I thought I would mention it.
Welcome onboard,
https://forum.onshape.com/discussion/123/ecad-tool#latest
The post about it being a part catalog is the key. I can live with the current software, I am low end newb at that as well, but I spend 10% of my time on design, 80% on tracking down parts, symbols, footprints etc. It is miserable, and ANYONE who does a better job of providing easier to use libraries, perhaps a venture funded startup, would quickly take over the market. So far, all the efforts I have seen are an obvious attempt to lock users into their service. If you need/want 1 part they dont have, you start all over.
http://www.spiked3.com
I swear I tried for 10 minutes last night to drag a feature and gave up. Today, it worked fine. Often I run into something that doesnt seem right, and it is hard to tell if it me doing something wrong before I got there, or it really doesnt work as expected. And again a lot of it I think is from using something other than SW, so workflow that is muscle reflex to a lot of you, is totally foreign to me.
That said, I am still totally stoked about Onshape. I need to find the roadmap if there is one, to see what things are planned. At the moment I am missing collada export, which is used to load robot models into simulators, as well as do product rendering. I'll keep looking.
http://www.spiked3.com
Wait till you try it on an ipad, it's really nice, but you do have to learn new muscle reflexes.
We don't currently support exporting the Collada .dae extension, but we do export STL, IGES, and STEP files, which Collada should support.
Additionally, we don't supply any sort of roadmap or planned features, but we welcome you to share your priorities and desired features with us at any time. Please feel free to post them to the forums or submit them through the feedback tool, and if you're really excited about getting a first look at some of what we're developing, please don't hesitate to reach out to us about doing user experience testing. We do, however, post a "What's New in Onshape" every couple weeks when we release a new version of the software.
UX/PD/Community Support
https://collada.org/
Unfortunately that is show stopper for me.
Also got word from my part maker he does not support your current DWG/DXF format either. 2nd show stopper. Calendar marked as a very depressing day.
Follow up; Collada is to the media world what step is to the CAD world. It is a requirement if you plan on showing renders before product is made. It is also one of the standards for loading into Robotic simulators and as such would be a demand from any factory planning on using the CAD for anything on the automation floor. Sure the big boys use STEP, but not the little guys. I am sure it is in the internal plans somewhere. As a small new company product rendering is a very high priority to me. Unfortunately its absence is also a catalyst for those that want to charge $100 / month for conversions or rendering services. Suddenly the good deal becomes not so good.
And BTW, I wrote a Collada exporter for another CAD program, so I know it isn't that hard
http://www.spiked3.com
http://www.spiked3.com
On a side note, nobody buys kinematics in a CAD package which I never understood, but I really want this capability. I think it has to be part of the base package inside Onshape otherwise it won't ever be used. Once the definitions are in Onshape then it's a matter of exporting. Not sure about XML as I prefer JSON. This might be a north vs. south thing and the good news is that we have some time as it sorts itself out.
One thing that might be true, if you used JSON, you might not need a "zipped" version of XML.
My actual Robotic message queuing is MQTT with JSON for when they are really working. ROS 2 has chosen DDS over MQTT so I might re-think down the road.
http://www.spiked3.com
I looked through a URDF listing and it seems to have the parent/child link relationship as well joint limits. Not sure of the units though. 3.14 as a maximum? Is this one full turn? With URDF I don't really see any link definitions is that what DAE does? Does DAE define the links and URDF controls the motion for the links?
MQTT has TCP/IP in it's stack, does this mean you can upload/download to a robot without a cable?
Summary:
DAE describes a linkage
URDF controls linkage
MQTT provides communication
How far off am I?
Philip_Thomas that DAE (aka Collada) also allows materials to be defined, as well as keeps parts separated (as opposed to STL). This saves a lot of work when you go to improve materials for a render.
URDF is indeed for linkages, as well as specifying which DAE files (or actually parts within) are being linked. My guess is a rotation of 3.14 might have some to do with Pi
MQTT is indeed TCP/IP - so that means wired or wireless. MQTT-SN is a variation (being merged) that define wireless serial (eg BlueTooth and others).
Not meaning to spam, but I'm a robot nut, check out my web page in my sig if you haven't already.
http://www.spiked3.com
Thought DAE was differential-algebraic equations
URDF threw me off because I was expecting unitized vectors 0 to 1 values and rotation matrices. Not sure why they deal with pi but didn't spend that much time looking at their XML definitions. I thought there would be more linear algebra in there definitions since it's a robotic linkage program. Thats what I get for poking around instead of reading the manual.
BTW-nice website
http://www.spiked3.com
Spiked3 we're not finished here, we're only beginning. Will you be able to export from OS to some robotic linkage standards? It's going to happen. It's gotta happen.
These existing robotic linkage standards seem to revolve around the old desktop data XML transfer standards and we need to migrate to a cloud data exchange standards JSON. This argument is only going to fester and we're going to see this argument more and more as cloud apps become more prominent.
I look forward to working on this with you,
Mapping/Conversion from low level mates to kinematic joints had been a tough and lossy process from system like Solidworks because users many times (unknowingly) model constraints which didn't represent valid motion model or model a simple joint between two components using a set of mates/constraints between multiple components. In Onshape it should be very straight forward and almost loss free once we have our APIs available.
BTW does anybody here use Mathwork's tools and would benefit from Data transfer to/from those tools? Do you guys also see any need to transfer motion output/profile from existing robotics kind of simulators into Onshape or doing associative multi-shot export/update?
The things I need most from a mechanical model are mass properties, link reference points, and hull geometry (for collision detection and visualization).
I don't use Mathworks tools and would not benefit from that. I have not yet found any motion tools integrated with CAD to be useful. Unless your motion tools were extraordinarily open I'd prefer to use my own which have project specific optimizations or simplifications.
For mass properties: I tend to model assemblies around the actual assembly process, in which case physical joints are often buried in a sub-sub-assembly. Being able to tag assemblies and parts as belonging to one link (rigid body) or another, combined with the ability to take the mass properties of query results, would let me automatically extract the information I need (which is the mass properties of the in-progress design).
For hull geometry, again I'd like to extract the geometry of a link by querying the model for a tag (again, because links rarely match assemblies) and export a mesh in any common format.
Being able to tag mate connectors or other reference points and extract their pose relative to some ground reference (the origin is fine) is the last piece of the puzzle for me.
Note that I'm not asking for any specific format of import or export. Put your energy into documenting the native API and it will be easy enough for us to convert to what we need. I'd rather you guys spent your time really refining the generic API for attaching user parameters wherever we want them in the model (ie to parts, features, sketches, sketch elements, geometry, relations, configuration parameters, etc) and querying the model, than spend time on canned and limited "features".
The trig involved is say you are describing a wrist, and I am simplifying for both you and me, I might describe the arm part connected to the hand part, connected on the arms X axis, The hands Z Axis and that it can rotate 180 degrees. I need to describe the geometries, connection axi for each part, but only a pitch/roll/yaw axis for one, I might choose arm 0,3.14,0 since I used it's X axis (roll). The math (IK and rendering) use trig to resolve their solutions. For example given a hand at x=4,y=8,z=9 where will the part be if I rotate the elbow 13 degrees? I may have X/Y = roll/pitch backwards, but I hope you get the idea.
Like I said I already have dug enough into it to know extracting the information I needed to render (collada/DAE) from the CAD I used was easy. And I had started looking into also extracting its constraint data, and translating that to what is called Rigging data in Blender, never quite finished it (or learnt as much about it in collada as I could have). But since then, I became more involved with programs that use URDF (Unified Robot Description Format) and it is also similar to constraint/rigging data - I was hoping to kill 2 robots, err birds, with one stone, both animated renders AND simulator ready robots.
Traveler Hauptman takes it a notch forward and calculates how much power it needs to move and how long it will take, and probably acceleration/deceleration profiles as well (motion planning). I am not that far along. And I agree with him, give us access to the base info, we'll figure out how to do something with it, or explain why we need/want it different.
BTW its 3.1415926535 (from memory :P )
http://www.spiked3.com
@Spiked3 Always room in the field for an enthusiast at any level! Maybe your collada experience was better than ours. I hope so given how frustrating it was for us.
In the end we bailed on collada and used stl to store meshes and some hand-rolled tools to help the CAD->simulation conversion process.
http://www.spiked3.com
As long as the awesome Onshape guys give us an API to their tesselator, it will be all good.
Assembly hierarchy rarely corresponds with how the model is divided up for a rigid body model. In case you are not familiar with this issue, think about a rotary joint using a ball bearing. The ball bearing is usually represented as a part, or a subassembly. However for a rigid body model, half the bearing belongs to the mass properties of one link and the other half to the other link. (every once and a while the speeds are high enough that you need to treat the individual balls separately; but not usually).
Thus the importance of tagging part instances and sub-assemblies, querying them, and extracting geometry and mass properties from a disparate group of parts.
Motion analysis tools change project to project. I had one colleague that liked ansys (but he had a heavy FEA background). I've not heard of anyone doing this type of work using SolidWorks Motion Studies for instance. I have always rolled my own. Python or C++ these days; Octave back in the days I could still stomach Matlab.
The reason I roll my own is that the complexity and focus of the model really depends on the project.
There are rigid body dynamics libraries out there but they are often focused on an idealized robot where joints are infinitely stiff in all directions except the frictionless one. As a designer of these devices I'm interested in the reaction forces experienced by the joint bearings among other things; something few models expose and many model's can't calculate at all (because they use a Lagrangian formulation).
Sometimes it's a simple device but we need an analytic solution to the Hessian matrix. Sometimes the inertia of the motor rotors and the force they impart on the link they are embedded in need to be accounted for in the dynamics. Sometimes the transmission has different efficiency forward-driving and back-driving and we need to account for that. The limiting factor in many high performance robots is not motor strength but instead motor temperature and our ability to remove the heat; so the model will track (very crudely) the thermal state of the motor as the desired dynamics are simulated.
Even libraries maintained internally or for a specific project get rewritten because they have the wrong simplifications or assumptions.
So, for me no model ever makes the right set of trade-offs for all projects. (I'm pretty specialized... Automation integrators might be better able to take advantage of a general tool.)
My pain point is getting mass and geometry info out of the solid model and into my own model.
Bottom line: you guys focus on your job and I'll focus on mine
http://www.spiked3.com
Some of the best code SW wrote was converting the assembly mates to ADAM's kinematics solver (I think they were mapping to ADAM?). This was the early days of motion inside of SW, at first kinematic joints were user defined and then magically they started to appear from the assembly constraints. Every assembly I threw at the converter worked very well and some of the best code I've seen. Did you work on that mapping? It was pretty good stuff. Vertex to vertex mapped perfectly to 3 rotational DOF's. I was amazed at how well it worked.
Mate connectors are definitely closer to kinematics joints required for robotics. In fact I was wondering if this was the inspiration behind mate connectors.
here's an example
We used a SW sketch to solve this determinant 4 bar linkage problem:
move to here with this angle:
we used SW to tell us what the linkage lengths needed to be and compute the position:
We threw the design out because field service would never have been able to figure out how to service this machine. You really had to model the links in cad to determine the solution. Not something you'd want to do onsite at a customer.
What I really wanted to know was the reactionary forces on the shoulder bolts. Because this linkage is so small, you could arrange things and get force spikes at the joints.
Velocity and acceleration profiles would also be nice to see. We knew the linear actuator force and the weight of the links it'd be nice to predict the speed of the device and the reactions at the joints.