new tractor idea possibly....
- Thread starter boggen
- Start date
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
it been mulling over my mind, last couple days. of some sort of "joint partnership" between some of the larger companies and smaller companies that are in direct business, of tractors / farming / ranching, etc... not to out compete against each other. but almost locking them together in a given X dollars and percentage, for a given time span. for R&D, and then once created and final working SSTT comes out. secondary phase hitting. of marketing / sale of the SSTT and implements. it has happened a good amount in the technology industry. for example VHS and BETA video, along with CD's/DVD's for music to video. were companies joined in a partnership, to find out the best doing they could find, and did there best to out compete other companies on there own. allowing the partnership to allow best of the best to work... and to also reduce overall "budget" for R&D.
so out of my league and above my head to pull something like above off. :shocked: though at this moment if that is what it took. i would give it my best shot.
=================
if i did the SSTT on my own....
i would imagine a couple weeks to couple months, to learn the current 3D model software versions and get some what proficient in one of them. and see about gaining access to some sort of repository of pre made 3D objects (gears, wheels, cylinders, engines, pumps, motors, etc..)
get some 3D models going. and then see about finding some funds to help pay for some extra 3D model artists. with back ground in engineering... and work things out from there. to a point were... i would most likely have to fall back on finding more money, or company, willing to take things to a certain point of fine tuning it, and then building the SSTT. which i would still most likely have to fall back onto a larger world wide company.
====================
====================
====================
i gotta assume someone some were has already thought about something like the SSTT. (so far searching has not returned anything). so i have to assume. some of the following....
the overall idea of the SSTT. was to much to sell to farmers. vs just making a larger current age tractor and implements, and doing OH by the way, you need this custom hitch type in category 3 / category 4 / category 5 hitches.
or someone went through the entire idea of a SSTT and found the overall weight was to much. or perhaps the complexity of the idea was enough to push some folks off the idea quickly.
is it because the various grades of metals, and manufacturing proccess of metals just have not caught up. and become more main stream yet to make it worth while?
is it because technology, as in computer chip type of doings and automation just has not caught up at the time of the idea. to allow things?
is it the old "folks not wanting to take ease to change" and being bull headed. and lets just toss a bigger hammer at it... err bigger tractor.
or has things been allowed, so farmers can get away with getting various permits or what not from the various levels of government to run there machinery on the roads. and really hammering down on when machines can be ran during daylight hours with good visibility? since these larger machines only run the roads normally during planting and harvesting times of the year?
has it been easier, to let farmers just deal with all the logistics. of moving trailers carrying implements back and forth between fields. and moving tractor by itself between fields and then getting everything hooked up and ready to go? due to roads and any other restraints would not allow tractor and implement go down the road without taking up the entire width of the road...
i honestly doubt the entire world in all the off beaten roads have the funding let alone ability to enlarge roads to accommodate larger width tractors and implements... to allow for much wider size machines. before roads start getting closed down temporarily to let a tractor get from field to field... which i doubt that would fly with local folks... along with any sort of emergency vehicles (ambulance, firetrucks, police)
is it to a point, were engine HP (horse power) got to were things are more than what can be put to wheels / tracks that could make SSTT more viable solution.
is it that when actually "measuring" things out. that is not physically possible to create a SSTT without making it "wider" than 8 feet including implements placed on it?
i really can not buy into some sort of limit placed on LCV (long connected vehicles) placed on interstate highways of the USA. as a factor, as in being only in place for a few years. and more to the point i doubt a SSTT would be driven on interstate highway. with min speed limit of 45 MPH.
has it been easier if a farmer needed more "width" in the fields, to sale them another tractor and implement, or another harvester. to get wanted width vs building something that would more likely. connect something like a train. and only require a single person to operate the extra width.
is the "cab" itself the major problem of the SSTT? as in needing ability to get the farmer up higher and into the air. so they have a better visual range across the entire width of the implement or harvester?
the idea of trying to watch out for "clogs" both on implements and harvesters. gets me some. ya there is need to be able to look for it. but really? when there are so many sensors and pieces of metal moving around. and then shields and panels placed over things. is it really even possible to get a complete eye on things vs relying on sensors on current age tractors in the last few years. it has gotten past the point of watching every single inch or foot that the implement / harvester goes through in the field. to a broad range view of a couple feet or more and due to distance and not being able to pick something "small" from a distance.
is the simple complexity of computers and sensors and making different things work together the problem? as a physical command point of view in the cab?
i am not looking for a complete automated self driven unit. were a computer makes every single choice. to get from point A to point B in a off road setting. i am simply looking at adding some extra computerized command routines. were a farmer / driver still has control of raising / lowering implements, how many MPH to go. when to stop and start, when to manually take control of a section. to keep things going correctly.
======================
computer programming..... finally... i think this may be the actual major problem. of the SSTT, why not seen yet in the fields / being made.
so out of my league and above my head to pull something like above off. :shocked: though at this moment if that is what it took. i would give it my best shot.
=================
if i did the SSTT on my own....
i would imagine a couple weeks to couple months, to learn the current 3D model software versions and get some what proficient in one of them. and see about gaining access to some sort of repository of pre made 3D objects (gears, wheels, cylinders, engines, pumps, motors, etc..)
get some 3D models going. and then see about finding some funds to help pay for some extra 3D model artists. with back ground in engineering... and work things out from there. to a point were... i would most likely have to fall back on finding more money, or company, willing to take things to a certain point of fine tuning it, and then building the SSTT. which i would still most likely have to fall back onto a larger world wide company.
====================
====================
====================
i gotta assume someone some were has already thought about something like the SSTT. (so far searching has not returned anything). so i have to assume. some of the following....
the overall idea of the SSTT. was to much to sell to farmers. vs just making a larger current age tractor and implements, and doing OH by the way, you need this custom hitch type in category 3 / category 4 / category 5 hitches.
or someone went through the entire idea of a SSTT and found the overall weight was to much. or perhaps the complexity of the idea was enough to push some folks off the idea quickly.
is it because the various grades of metals, and manufacturing proccess of metals just have not caught up. and become more main stream yet to make it worth while?
is it because technology, as in computer chip type of doings and automation just has not caught up at the time of the idea. to allow things?
is it the old "folks not wanting to take ease to change" and being bull headed. and lets just toss a bigger hammer at it... err bigger tractor.
or has things been allowed, so farmers can get away with getting various permits or what not from the various levels of government to run there machinery on the roads. and really hammering down on when machines can be ran during daylight hours with good visibility? since these larger machines only run the roads normally during planting and harvesting times of the year?
has it been easier, to let farmers just deal with all the logistics. of moving trailers carrying implements back and forth between fields. and moving tractor by itself between fields and then getting everything hooked up and ready to go? due to roads and any other restraints would not allow tractor and implement go down the road without taking up the entire width of the road...
i honestly doubt the entire world in all the off beaten roads have the funding let alone ability to enlarge roads to accommodate larger width tractors and implements... to allow for much wider size machines. before roads start getting closed down temporarily to let a tractor get from field to field... which i doubt that would fly with local folks... along with any sort of emergency vehicles (ambulance, firetrucks, police)
is it to a point, were engine HP (horse power) got to were things are more than what can be put to wheels / tracks that could make SSTT more viable solution.
is it that when actually "measuring" things out. that is not physically possible to create a SSTT without making it "wider" than 8 feet including implements placed on it?
i really can not buy into some sort of limit placed on LCV (long connected vehicles) placed on interstate highways of the USA. as a factor, as in being only in place for a few years. and more to the point i doubt a SSTT would be driven on interstate highway. with min speed limit of 45 MPH.
has it been easier if a farmer needed more "width" in the fields, to sale them another tractor and implement, or another harvester. to get wanted width vs building something that would more likely. connect something like a train. and only require a single person to operate the extra width.
is the "cab" itself the major problem of the SSTT? as in needing ability to get the farmer up higher and into the air. so they have a better visual range across the entire width of the implement or harvester?
the idea of trying to watch out for "clogs" both on implements and harvesters. gets me some. ya there is need to be able to look for it. but really? when there are so many sensors and pieces of metal moving around. and then shields and panels placed over things. is it really even possible to get a complete eye on things vs relying on sensors on current age tractors in the last few years. it has gotten past the point of watching every single inch or foot that the implement / harvester goes through in the field. to a broad range view of a couple feet or more and due to distance and not being able to pick something "small" from a distance.
is the simple complexity of computers and sensors and making different things work together the problem? as a physical command point of view in the cab?
i am not looking for a complete automated self driven unit. were a computer makes every single choice. to get from point A to point B in a off road setting. i am simply looking at adding some extra computerized command routines. were a farmer / driver still has control of raising / lowering implements, how many MPH to go. when to stop and start, when to manually take control of a section. to keep things going correctly.
======================
computer programming..... finally... i think this may be the actual major problem. of the SSTT, why not seen yet in the fields / being made.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
computer programming....
how does the machine work... and how and what sensors would be needed. to allow it to work. i think i have been taking the programming for granted. and more specifically the functions / routines of the code, and just assuming it would be common ability and initiative, in coding scheme. and then writing some top level functions to let the farmer/driver select what they wanted to have done via some computer screen / user interface.
*ughs* that is the one thing i hate about computer programing. "flow charts" of the "if, then / else" and running through another function for this or that. things become so integrated into different functions. that it makes flow charts turn into globs of mess...
i guess it would come down like usual breaking things down into smaller chunks of code.
i would imagine there would be a database (lists) of....
--sensor type (RPM, length, pressure)
--location of were sensor is used (short description of what it is)
--min / max abilty of sensor (length, RPM's, etc...)
--when diagnostics are done and more to the point calibrations are done. these values get set for min/max or list of variables to get a correct plot point curve. for a given doings.
not about to go through full idea list of functions here...
sensors would already be in place to sense RPM for tires or tracks, or distances a cylinder rod moved. and should be all that would needed. to actual control the unit via a computer.
though i would imagine the network protocol used, (going to assume digital over analog network) and some sort of well i guess it would be old school master/slave server setup. or perhaps network clustering topography for networking, between chips that sensors plug into. and perhaps some sort of extra chip or 2 on each section.
i would imagine it would come down to network protocol, equations used in functions. and "lag" or latency between commands being issued and something moving. and how much slop in lag there can be. while still maintaining a working unit that is not trashing itself from sudden commands being issued that are out of sync with other commands.
poor brain about ready to go bankrupt trying to remember various topographies for network setups. that might explain better with least amount of wording.
i am not sure a typical every day network protocol would work. even after assigning ID's, and pings, and some security and checks and balances... and instead of trying to find something, might be easier to say just do this that, and be done with it. errr then again never mind easier said than done and speaking without researching first.
============
sensors will be the "down fall" of the SSTT. the sensors will need to be built heavy duty enough to withstand things. but also cheaply made and accurate, and more to the point easy to swap in and out to be replaced.
again not a fan of a computer chip or like directly built into a sensor. give me 2 to 4 wires off the sensor. and run them back to up onto the SSTT were a chip could allow connections of various sensors. it moves some cost from sensors to a some smaller sized computer chips. and guessing a little bit more for a chip. but going to assume benefits would out weight the cons fairly quickly.
============
because of how tightly nit the coding would most likely become. i am on edge. of finding the couple people that have the expertise. and let them do there thing even if it means taking longer. vs going with more coders. and getting blob ware that just slows everything down.
let the couple coders do there thing. and then add on GUI (graphical user interface) folk/s. to create a user interface screen, for diagnostics, and the driver of the SSTT.
though stating above, and working things out is completely different story. (always depends)
============
wondering if there might be need for a double network.
1 for cameras, and "logs", and data sent back to the farmer/driver in the cab.
1 for sensors and commands to valves and like.
perhaps the 1 for cameras, might be used for a center server at the cab. to run larger functions / routines
and then the 1 for sensors and valves, a special network protocol. that is really stream lined down for fast commands and sensor data, without all the overhead of a typical network protocol.
============
i am looking so far ahead at this point, for programing aspect and sensor / valve doings. that i am having rough time even being able to make a statement that could be taken as a fact. due to i would imagine most of this would come in after a working 3D model came into play. or at least some first beta version. just to give programmers something to work with. for distances, and amount of sensors...
well no that would just push things back further....
i guess it would come down, making a list of sensors and valves, and amount of them. for each type of implement, or tire/tracks, implement linkages, etc...for the SSTT. and giving some sort of wider range / narrow range of what would come back from things...
then getting a list of functions / routines and what they do, and breaking things up and assigning things out. to at least get a head start. vs a time lag between getting a 3D model going and some sort of simulator and along with a finish physical working machine.
how does the machine work... and how and what sensors would be needed. to allow it to work. i think i have been taking the programming for granted. and more specifically the functions / routines of the code, and just assuming it would be common ability and initiative, in coding scheme. and then writing some top level functions to let the farmer/driver select what they wanted to have done via some computer screen / user interface.
*ughs* that is the one thing i hate about computer programing. "flow charts" of the "if, then / else" and running through another function for this or that. things become so integrated into different functions. that it makes flow charts turn into globs of mess...
i guess it would come down like usual breaking things down into smaller chunks of code.
i would imagine there would be a database (lists) of....
--sensor type (RPM, length, pressure)
--location of were sensor is used (short description of what it is)
--min / max abilty of sensor (length, RPM's, etc...)
--when diagnostics are done and more to the point calibrations are done. these values get set for min/max or list of variables to get a correct plot point curve. for a given doings.
not about to go through full idea list of functions here...
sensors would already be in place to sense RPM for tires or tracks, or distances a cylinder rod moved. and should be all that would needed. to actual control the unit via a computer.
though i would imagine the network protocol used, (going to assume digital over analog network) and some sort of well i guess it would be old school master/slave server setup. or perhaps network clustering topography for networking, between chips that sensors plug into. and perhaps some sort of extra chip or 2 on each section.
i would imagine it would come down to network protocol, equations used in functions. and "lag" or latency between commands being issued and something moving. and how much slop in lag there can be. while still maintaining a working unit that is not trashing itself from sudden commands being issued that are out of sync with other commands.
poor brain about ready to go bankrupt trying to remember various topographies for network setups. that might explain better with least amount of wording.
i am not sure a typical every day network protocol would work. even after assigning ID's, and pings, and some security and checks and balances... and instead of trying to find something, might be easier to say just do this that, and be done with it. errr then again never mind easier said than done and speaking without researching first.
============
sensors will be the "down fall" of the SSTT. the sensors will need to be built heavy duty enough to withstand things. but also cheaply made and accurate, and more to the point easy to swap in and out to be replaced.
again not a fan of a computer chip or like directly built into a sensor. give me 2 to 4 wires off the sensor. and run them back to up onto the SSTT were a chip could allow connections of various sensors. it moves some cost from sensors to a some smaller sized computer chips. and guessing a little bit more for a chip. but going to assume benefits would out weight the cons fairly quickly.
============
because of how tightly nit the coding would most likely become. i am on edge. of finding the couple people that have the expertise. and let them do there thing even if it means taking longer. vs going with more coders. and getting blob ware that just slows everything down.
let the couple coders do there thing. and then add on GUI (graphical user interface) folk/s. to create a user interface screen, for diagnostics, and the driver of the SSTT.
though stating above, and working things out is completely different story. (always depends)
============
wondering if there might be need for a double network.
1 for cameras, and "logs", and data sent back to the farmer/driver in the cab.
1 for sensors and commands to valves and like.
perhaps the 1 for cameras, might be used for a center server at the cab. to run larger functions / routines
and then the 1 for sensors and valves, a special network protocol. that is really stream lined down for fast commands and sensor data, without all the overhead of a typical network protocol.
============
i am looking so far ahead at this point, for programing aspect and sensor / valve doings. that i am having rough time even being able to make a statement that could be taken as a fact. due to i would imagine most of this would come in after a working 3D model came into play. or at least some first beta version. just to give programmers something to work with. for distances, and amount of sensors...
well no that would just push things back further....
i guess it would come down, making a list of sensors and valves, and amount of them. for each type of implement, or tire/tracks, implement linkages, etc...for the SSTT. and giving some sort of wider range / narrow range of what would come back from things...
then getting a list of functions / routines and what they do, and breaking things up and assigning things out. to at least get a head start. vs a time lag between getting a 3D model going and some sort of simulator and along with a finish physical working machine.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
ya a little crazy, but would not read to much into things.Wow this thread is intense!
but gotta ask, so are you the urban legend, of the bozo that built something due to money burning a hole in there pocket, and not letting the team do there job completely? *shakes head* kids and there toys.
as far as leaving name and short email to Caterpillar. some family have been contracted with Caterpillar and friends of everyone knows someone that either works directly or is / has been a contractor for Caterpillar. there Head quarters and one of there R&D, and assembly plants are in reasonable driving distance from me for an actual doing. ya Caterpillar shows more for construction equipment and mining, vs farming industry, but i also see a lot of other vehicles in other industry Caterpillar makes. figured i might have a good chance of getting in a good team, that has wide spread knowledge and more likely be able to think out of the box per say. for a different tractor idea, and be a tad more open to possibilities not the company directly but the R&D staff that have had to create the various machines.
with Above said. most of contacting Caterpillar. is they are nearest to me. Who knows maybe they want to get into the farming industry and this might be there way in.
===============
though I just can not pass up John Deere being fairly close. one of there major industries is farming. they know there customers, they know there implements and harvesters. they understand the various crops. but i am severely lacking on knowledge of John Deere. and reason in a post earlier most likely take a visit and more likely a tour of there places near me to get a better grasp of things. Though for Now will just settle on a Email / phone calls Friday. and see if i can get a hold of someone. beyond showing up at the front desk of there headquarters.
i have nothing to loose at this point. just time / ideas / work noted here on this thread. i gotta see it through. and drive 1 of them SSTT what ever shape and form it comes out to be. perhaps it might be a foot hold. for LCV (long connected vehicles) (semi with 3 plus trailers behind it) get the low MPH units down and shown they can work. and work my way up to higher MPH machines and move the world! gotta start some were.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
some diagrams for the main frame (spine) of the SSTT
================
axial engine. don't know. i like idea of the length vs dimensions of width and depth. but not so sure about it. and looking at it, it might offer high torque, at lower RPMs. but unsure about that.
below image is from Axial Vector(TM) Engine Corporation Presents Its First Commercial Product Operating Status
i been iffy about this type of engine. really do not need high RPMS.
below image is from Aircraft Engines Explained and Types of Aviation Engines with References Animations Videos and Pictures
i keep going back the age old regular internal combustion engine.
though i am second guessing placement under the spine / main frame. vs building the engine and hyd pumps into the the spine / main frame. or perhaps placing them above the spine / main frame.
looking at first diagram posted in this post. i am uneasy, trying to place some sort of "mounting" brackets on edges of engines and hyd pumps. without any sort of actual frame under or around the engines and hyd pumps and just relying on the metal of them to act as a structural support. i could see things just tearing apart and just wrecking the SSTT.
was thinking about running hyd oil lines, coolant lines into the main casted metal shell for the spine. but that does not really work come time to manufacture / creating the casted shell.
thought about splitting the 60 foot section up into "chunks" say 5 to 10 feet long. but that brings me right back to issues of creating places for bolts and just breaking things in half.
i suppose the things could be welded together. to allow for different doings, but...but... hmmmsss trying to get into anything to fix it, once initial welding was done...
================
axial engine. don't know. i like idea of the length vs dimensions of width and depth. but not so sure about it. and looking at it, it might offer high torque, at lower RPMs. but unsure about that.
below image is from Axial Vector(TM) Engine Corporation Presents Its First Commercial Product Operating Status
i been iffy about this type of engine. really do not need high RPMS.
below image is from Aircraft Engines Explained and Types of Aviation Engines with References Animations Videos and Pictures
i keep going back the age old regular internal combustion engine.
though i am second guessing placement under the spine / main frame. vs building the engine and hyd pumps into the the spine / main frame. or perhaps placing them above the spine / main frame.
looking at first diagram posted in this post. i am uneasy, trying to place some sort of "mounting" brackets on edges of engines and hyd pumps. without any sort of actual frame under or around the engines and hyd pumps and just relying on the metal of them to act as a structural support. i could see things just tearing apart and just wrecking the SSTT.
was thinking about running hyd oil lines, coolant lines into the main casted metal shell for the spine. but that does not really work come time to manufacture / creating the casted shell.
thought about splitting the 60 foot section up into "chunks" say 5 to 10 feet long. but that brings me right back to issues of creating places for bolts and just breaking things in half.
i suppose the things could be welded together. to allow for different doings, but...but... hmmmsss trying to get into anything to fix it, once initial welding was done...
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
sent a "other contact" short form on John Deere website, last night, and then hunted for phone number and ended up on "sponsorship" area of John Deere website. and start to fill out a form. *shrugs* it gives space to fill out info. so at moment currently have it saved. will wait till later on tonight after had some time to think. before actually submitting it. "don't know" never been through this type of process before.
i mean its not like taking a product to a store like Wal-Mart or like, to get your product up on the shelves.
i suppose, i might have to go see about one of them "shows" was it "sharks?" and see if netflix or like has them on DVD and actually watch those shows. to get some ideas. for development ideas and bring things to the high ups... but don't know.
*shrugs* trail and error. off to get busy with other stuff.
i mean its not like taking a product to a store like Wal-Mart or like, to get your product up on the shelves.
i suppose, i might have to go see about one of them "shows" was it "sharks?" and see if netflix or like has them on DVD and actually watch those shows. to get some ideas. for development ideas and bring things to the high ups... but don't know.
*shrugs* trail and error. off to get busy with other stuff.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
last night and good portion of today, been thinking of what has not been touched on.
the sensors, valves, computer/chip programming. are high up on list to go through better.
really need to get a grid going, and actually do the math to figure out approx measurements, for tracks, AG/R1 tires, implement linkages, linkages between sections. without know those min/max approx measurements the main frame (spine) for the SSTT is a toss up.
thinking about the form deal with John Deere to fill out, and got me thinking i really way over my head still. in amount of info wanted. money, to details, etc... would be nice to skip that info, and let someone else worry about it. but i doubt that is going to happen. without getting some idea of costs of things.
though at moment, I am almost expecting to almost have to juggle a few things. as in few different companies / third party contractors to them. just to get the things created and done. to obtain a working physical prototype.
*legos* *waves* off to the storage room or shed and see if i can find those old legos i had as toys. though the pneumatics got destroyed long, long ago...
but before i go do that, i think i will just submit the form on JD website. just to get things started, And as things come up, go from there. until then forging ahead... regardless.
the sensors, valves, computer/chip programming. are high up on list to go through better.
really need to get a grid going, and actually do the math to figure out approx measurements, for tracks, AG/R1 tires, implement linkages, linkages between sections. without know those min/max approx measurements the main frame (spine) for the SSTT is a toss up.
thinking about the form deal with John Deere to fill out, and got me thinking i really way over my head still. in amount of info wanted. money, to details, etc... would be nice to skip that info, and let someone else worry about it. but i doubt that is going to happen. without getting some idea of costs of things.
though at moment, I am almost expecting to almost have to juggle a few things. as in few different companies / third party contractors to them. just to get the things created and done. to obtain a working physical prototype.
*legos* *waves* off to the storage room or shed and see if i can find those old legos i had as toys. though the pneumatics got destroyed long, long ago...
but before i go do that, i think i will just submit the form on JD website. just to get things started, And as things come up, go from there. until then forging ahead... regardless.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
found the lego's got frustrated, hit the shop, and found some small dole rods, got some cigarettes, took the tobacco out of them. and ended up using 2 cigarettes with nothing in them. to act like cylinders. got some twisties (bread ties / garbage ties) and ran them through the filters on the cigarettes and through some lego's (could have been card board).
i got something functional but, how in the world do you go through all the variables. for the "implement linkages"
thinking it might be easier, to create a program, and feed it some variables and constants. and let it go through 1,000 to millions of irritations or more.
--solid bars (set min / max length, with irritating through say 1/16"
--cylinder (set min / max length, with irritating through say 1/16"
--put in a transport tire to act like a blockage
--put in a implement that is say 12 to 14 feet long
--put in physical dimensions from surface up to say 14 to 16 feet
--put in 2', 4', 6' 8' limitations from edge of tire on one side, to edge of tire on other side
--double it up for implement linkages on both sides.
--gravity or like, constant. that causes things to fall. to keep everything down to earth and not free floating.
--give program option of were solid bars / cylinders connect to each other along with on the implement
--give a start / stop (implement folded down and into the dirt say 20 inches, and then folded up in transport mode.)
--add a database into the mix, and if it passes put it into the database.
--be able to select a database set, and reply it in some sort of animation software.
then again perhaps run another heavier set of requirements, with weight involved, and simple cylinder math. and place a time stamp on, "start to finish" between folding / unfolding and then back to folding. (in attempt to narrow things down even further) perhaps setting the max PSI valve feeding cylinders... and diameter of the cylinders as another limitation. along with overall length of cylinders + rods.
--weight would be physical weight of implement. without taking anything else into consideration for weight. keep it simple.
=================
a simple x,y (2D) grid should work.
its getting way to late to think clearly.
i got something functional but, how in the world do you go through all the variables. for the "implement linkages"
thinking it might be easier, to create a program, and feed it some variables and constants. and let it go through 1,000 to millions of irritations or more.
--solid bars (set min / max length, with irritating through say 1/16"
--cylinder (set min / max length, with irritating through say 1/16"
--put in a transport tire to act like a blockage
--put in a implement that is say 12 to 14 feet long
--put in physical dimensions from surface up to say 14 to 16 feet
--put in 2', 4', 6' 8' limitations from edge of tire on one side, to edge of tire on other side
--double it up for implement linkages on both sides.
--gravity or like, constant. that causes things to fall. to keep everything down to earth and not free floating.
--give program option of were solid bars / cylinders connect to each other along with on the implement
--give a start / stop (implement folded down and into the dirt say 20 inches, and then folded up in transport mode.)
--add a database into the mix, and if it passes put it into the database.
--be able to select a database set, and reply it in some sort of animation software.
then again perhaps run another heavier set of requirements, with weight involved, and simple cylinder math. and place a time stamp on, "start to finish" between folding / unfolding and then back to folding. (in attempt to narrow things down even further) perhaps setting the max PSI valve feeding cylinders... and diameter of the cylinders as another limitation. along with overall length of cylinders + rods.
--weight would be physical weight of implement. without taking anything else into consideration for weight. keep it simple.
=================
a simple x,y (2D) grid should work.
its getting way to late to think clearly.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
continuing off of last post...
what would be needed to accurately compute things?
---rotation ? or rather degrees of rotation?
---length measurement of course.
---center of each hole (were a pin would go) or rather make that center of the hinge point.
*rubs chin* how do you go back and forth between hyd cylinders....
i suppose loops within loops within loops, or rather, for each cylinder, the computer puts in, a "loop" would be done.
---FOR EACH (X, in Y_cylinders, step Z <= Y_cylinders_max_extending)
-----call function
-----another loop...
-------call function
-------another loop...
the functions. are going to need to go through each extending and contracting of each cylinder in say increments of 1/64" of an inch.
if i keep following this path of thought, it could take a long time for a heavy duty server to go through enough variations to get something back... that could even be useable...
there needs to be a way for computer to "track" lengths of bars / cylinders and were they connect... yikes... feel sorry for database.
--perhaps incrementing a number.
--but still the database would get large. even with using a secondary table. just to hold data for tracking, and another table for things that pass.
there needs to be a way to limit how many "solid bars" and how many "cylinders", and how many points of connections (pins / hinge points) just to reduce and stop a non ending loop...
also there needs to be a way to limit how close (pin / hinge / pivot) point happens to another. or less on same x,y axis plot point.
---solid bars, and then simply Teeing off up off of bar for a cylinder attachment point... (off set amount) yikes..
---i suppose you could limit solid bars extending off of other solid bars via only in perpendicular notation at fixing the point so they do not hinge / pivot.
---then placing some sort of variable / constant by user. of how many perpendicular bars could be done. guessing 3, times, maybe up to 5 times max.
===============
there would need to be limiting boundaries for implement.... so implement side (furthest away from SSTT)) does not bend down, when it is being folded to transport mode. so it does not "tip" the SSTT over
the "box shape" of an implement would not be allowed to go into the transport wheel areas. along with under the transport wheels.
--but linkages (solid bars and cylinders could go through wheels)
--so looking at perhaps a secondary layer per say. for boundary points. i should say collision points.
===============
===============
===============
===============
===============
min/max length
--solid bars ======= solid metal bar. Like lower link arms on a 3pt hitch.
--cylinders ======= hydraulic cylinder
--rod of cylinders ======= a rod only extends / contracts so far. These settings give the space needed for seals, and spots for hyd hose hook ups, and like
--rod length ======= this is how far a ROD is extended (beyond the contracting / extending) that is taking into account with cylinder.
--implement connection 1 ======= distance a solid bar can come off the implement for a hinged point
--implement connection 2 ======= second connection point.
--implement connection 1 ======= how far back on implement connection can be
--implement connection 2 ======= second connection point.
min/max (how many)
--connecting points ======= how many (hinged / pivot / pins) can there be
--cylinders ======= how many cylinders can be used
--straight solid bars ======= how many straight solid bars that there can be.
--off set solid bars ======= how many times a perpendicular solid bar can come off another straight solid bar.
increments for lengths for the next "LOOP" irritation
--solid bars
--cylinders
--off set solid bars
--rod length
increments +/- for computer to extending or contracting a cylinder during each loop.
x,y plot points
--fixed position x,y plot points ======= hinged / pivot points that solid bars, or cylinders or rods connect to. but points never move ((think of them as points connected directly to frame of the SSTT))
--dynamic position x,y plot points ======= for connection points between cylinders, rods, solid bars. that change based on movement of a hyd cylinder
--4 sets of X,Y plot points. --transport wheels ======= just treat them as a box shape, area were implement can never move into.
--4 sets of X,Y plot points. --transport wheels, (opposite side)
--4 sets of X,Y plot points. physical boundry limits of everything. ======= total height, total width. that anything can move within
--4 sets of X,Y plot points. linkages going below "axles" of tires. ======= exception... once linkages get past out side edge of wheels
--4 sets of X,Y plot points. location of implement when "unfolded" and down on the ground.
--4 sets of X,Y plot points. location of implement when "folded up" and ready for transport down the road.
--4 sets of X,Y plot points, that linkages (solid bars, cylinders, rods,) need to be within, when implement is fully folded up ready for transport mode.
--4 sets of X,Y plot points. dimensions of implement. ((assume top X,Y points = top frame of an implement))
boundary laws / conditions
--implement can never go into area of were wheels are.
--implements can never go past the physical over all boundaries (max/min height, min/max width)
--same goes for solid bars and cylinders.
--no solid bars, or cylinders can extend into an implement but may attach to implement
--no solid bars or cylinders, can extend below wheel axles with exception of being past outside edge of wheels.
--no solid bars or cylinders, can have fixed connection point (think connection point to frame of SSTT) below wheel axles.
pass/fail laws / conditions.
--an implement must fully fold and unfold, then fold backup again, then unfold one more time. without changing anything beyond extending / contracting cylinders.
--folding/unfolding all boundary laws/ conditions are taken into account.
pass/fail database
--record lengths, and X,Y plot points. for each solid bar, off set perpendicular bar, cylinder, rod. fixed connection points. and implement connection points.
--if it fails, nothing gets recorded to database.
saving/pausing/stopping/resume/loading program database
--just holds incremental numbers of everything? every time or perhaps after so many irritations. database records get updated?
--on resume, inserting code to load a specific setup of X,Y coordinates, and lengths, etc... for preset doings someone came up with?
=========
posting before i loose stuff.
what would be needed to accurately compute things?
---rotation ? or rather degrees of rotation?
---length measurement of course.
---center of each hole (were a pin would go) or rather make that center of the hinge point.
*rubs chin* how do you go back and forth between hyd cylinders....
i suppose loops within loops within loops, or rather, for each cylinder, the computer puts in, a "loop" would be done.
---FOR EACH (X, in Y_cylinders, step Z <= Y_cylinders_max_extending)
-----call function
-----another loop...
-------call function
-------another loop...
the functions. are going to need to go through each extending and contracting of each cylinder in say increments of 1/64" of an inch.
if i keep following this path of thought, it could take a long time for a heavy duty server to go through enough variations to get something back... that could even be useable...
there needs to be a way for computer to "track" lengths of bars / cylinders and were they connect... yikes... feel sorry for database.
--perhaps incrementing a number.
--but still the database would get large. even with using a secondary table. just to hold data for tracking, and another table for things that pass.
there needs to be a way to limit how many "solid bars" and how many "cylinders", and how many points of connections (pins / hinge points) just to reduce and stop a non ending loop...
also there needs to be a way to limit how close (pin / hinge / pivot) point happens to another. or less on same x,y axis plot point.
---solid bars, and then simply Teeing off up off of bar for a cylinder attachment point... (off set amount) yikes..
---i suppose you could limit solid bars extending off of other solid bars via only in perpendicular notation at fixing the point so they do not hinge / pivot.
---then placing some sort of variable / constant by user. of how many perpendicular bars could be done. guessing 3, times, maybe up to 5 times max.
===============
there would need to be limiting boundaries for implement.... so implement side (furthest away from SSTT)) does not bend down, when it is being folded to transport mode. so it does not "tip" the SSTT over
the "box shape" of an implement would not be allowed to go into the transport wheel areas. along with under the transport wheels.
--but linkages (solid bars and cylinders could go through wheels)
--so looking at perhaps a secondary layer per say. for boundary points. i should say collision points.
===============
===============
===============
===============
===============
min/max length
--solid bars ======= solid metal bar. Like lower link arms on a 3pt hitch.
--cylinders ======= hydraulic cylinder
--rod of cylinders ======= a rod only extends / contracts so far. These settings give the space needed for seals, and spots for hyd hose hook ups, and like
--rod length ======= this is how far a ROD is extended (beyond the contracting / extending) that is taking into account with cylinder.
--implement connection 1 ======= distance a solid bar can come off the implement for a hinged point
--implement connection 2 ======= second connection point.
--implement connection 1 ======= how far back on implement connection can be
--implement connection 2 ======= second connection point.
min/max (how many)
--connecting points ======= how many (hinged / pivot / pins) can there be
--cylinders ======= how many cylinders can be used
--straight solid bars ======= how many straight solid bars that there can be.
--off set solid bars ======= how many times a perpendicular solid bar can come off another straight solid bar.
increments for lengths for the next "LOOP" irritation
--solid bars
--cylinders
--off set solid bars
--rod length
increments +/- for computer to extending or contracting a cylinder during each loop.
x,y plot points
--fixed position x,y plot points ======= hinged / pivot points that solid bars, or cylinders or rods connect to. but points never move ((think of them as points connected directly to frame of the SSTT))
--dynamic position x,y plot points ======= for connection points between cylinders, rods, solid bars. that change based on movement of a hyd cylinder
--4 sets of X,Y plot points. --transport wheels ======= just treat them as a box shape, area were implement can never move into.
--4 sets of X,Y plot points. --transport wheels, (opposite side)
--4 sets of X,Y plot points. physical boundry limits of everything. ======= total height, total width. that anything can move within
--4 sets of X,Y plot points. linkages going below "axles" of tires. ======= exception... once linkages get past out side edge of wheels
--4 sets of X,Y plot points. location of implement when "unfolded" and down on the ground.
--4 sets of X,Y plot points. location of implement when "folded up" and ready for transport down the road.
--4 sets of X,Y plot points, that linkages (solid bars, cylinders, rods,) need to be within, when implement is fully folded up ready for transport mode.
--4 sets of X,Y plot points. dimensions of implement. ((assume top X,Y points = top frame of an implement))
boundary laws / conditions
--implement can never go into area of were wheels are.
--implements can never go past the physical over all boundaries (max/min height, min/max width)
--same goes for solid bars and cylinders.
--no solid bars, or cylinders can extend into an implement but may attach to implement
--no solid bars or cylinders, can extend below wheel axles with exception of being past outside edge of wheels.
--no solid bars or cylinders, can have fixed connection point (think connection point to frame of SSTT) below wheel axles.
pass/fail laws / conditions.
--an implement must fully fold and unfold, then fold backup again, then unfold one more time. without changing anything beyond extending / contracting cylinders.
--folding/unfolding all boundary laws/ conditions are taken into account.
pass/fail database
--record lengths, and X,Y plot points. for each solid bar, off set perpendicular bar, cylinder, rod. fixed connection points. and implement connection points.
--if it fails, nothing gets recorded to database.
saving/pausing/stopping/resume/loading program database
--just holds incremental numbers of everything? every time or perhaps after so many irritations. database records get updated?
--on resume, inserting code to load a specific setup of X,Y coordinates, and lengths, etc... for preset doings someone came up with?
=========
posting before i loose stuff.
OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,824
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
what other ways can be used to reduce the length of a full non stop run of the program from start to finish.
increments for x,y coordinates, for distance fixed points (left to right) ((think connection points to frame of SSTT))
increments for x,y coordinates, for distance fixed points (up to down) ((think connection points to frame of SSTT))
the program does not need any sort of GUI (graphical user interface) perhaps simple command line? or text file command line feed. then use a secondary program. to pull "passes" from database and display and animate if need be.
================
without getting physical size / dimensions, stresses, etc.. of metal involved. that i would imagine take a good chunk of time to compute. when ever something passes. perhaps running a second program on database, that takes into account the extras. speeding up the initial run. but at cost of a large database?
i think, even trying to add "weight" and cylinder diameter, and like, on each pass, would considerably slow things down.
other words to above, there are going to be certain length ranges of solid bars to cylinders that things pass. and these ranges... will fill the database up quickly. till lengths get passed a certain point and things begin to Fail.
thinking running a quick very limited function program, and then having the secondary program. check the database to run a more complex thing. and in this secondary program. if something passes, add the info to another database, or delete record in the one database, or tagging the record with "fail"
=====================
*rubs chin* don't remember name of it, but it was a command line graphic editing routines. with ability to make simple 2D ".gif" animated pictures.
*rubs chin* animation... is what will be happening, but need to get my mind around, the physical "stepping" through each loop. to physically extend or contract a cylinder and have everything else. move with it. i guess it might resemble clay animation. well hhmmss...
start from "fixed" coordinates, and move first cylinder, then that x,y on end of rod, then need to decided on path. if 3 or more things pivot/hinge/rotate from a single x,y plot point...
i guess, i would rotate things around, a X,Y point. and then, rotate the next thing it connects to and were the 2 circumferences of each rotating piece meet. do a check vs last 2 moves. for path of direction of movement?
aaaaa.... getting over my head already. i guess i need to go a hunting, for physics for animation, and pathing tutorials. i do not think any of the 10 plus year books have anything in them. remotely of what would be needed.
increments for x,y coordinates, for distance fixed points (left to right) ((think connection points to frame of SSTT))
increments for x,y coordinates, for distance fixed points (up to down) ((think connection points to frame of SSTT))
the program does not need any sort of GUI (graphical user interface) perhaps simple command line? or text file command line feed. then use a secondary program. to pull "passes" from database and display and animate if need be.
================
without getting physical size / dimensions, stresses, etc.. of metal involved. that i would imagine take a good chunk of time to compute. when ever something passes. perhaps running a second program on database, that takes into account the extras. speeding up the initial run. but at cost of a large database?
i think, even trying to add "weight" and cylinder diameter, and like, on each pass, would considerably slow things down.
other words to above, there are going to be certain length ranges of solid bars to cylinders that things pass. and these ranges... will fill the database up quickly. till lengths get passed a certain point and things begin to Fail.
thinking running a quick very limited function program, and then having the secondary program. check the database to run a more complex thing. and in this secondary program. if something passes, add the info to another database, or delete record in the one database, or tagging the record with "fail"
=====================
*rubs chin* don't remember name of it, but it was a command line graphic editing routines. with ability to make simple 2D ".gif" animated pictures.
*rubs chin* animation... is what will be happening, but need to get my mind around, the physical "stepping" through each loop. to physically extend or contract a cylinder and have everything else. move with it. i guess it might resemble clay animation. well hhmmss...
start from "fixed" coordinates, and move first cylinder, then that x,y on end of rod, then need to decided on path. if 3 or more things pivot/hinge/rotate from a single x,y plot point...
i guess, i would rotate things around, a X,Y point. and then, rotate the next thing it connects to and were the 2 circumferences of each rotating piece meet. do a check vs last 2 moves. for path of direction of movement?
aaaaa.... getting over my head already. i guess i need to go a hunting, for physics for animation, and pathing tutorials. i do not think any of the 10 plus year books have anything in them. remotely of what would be needed.