OP
boggen
Elite Member
- Joined
- Feb 22, 2011
- Messages
- 3,789
- Location
- Trivoli, IL
- Tractor
- SSTT (Sideways Snake Tain Tractor) and STB (sideways train box) tractor, dirt harvester
larger hurdle reached...as far as programming, and what can be used for simpler computer chips.
post 15 pictures, show a u-join on both ends of each hyd cylinder. i was planning to put one u-joint on the cylinder end, and then a ball on the piston end. that is all good and all... but, the u-joint. i forgot about how a U-joint actually works, more so when ya bend the U-joint near 90 degrees. the two pieces want to act almost like a 4 toothed gear. if i went to adjust the "stewart platform" aka dog tail. a person could easily rotate and angle things enough to destroy the u-joints. example. moving dog tail off to one side. ((adjusting an off set rear blade, all the way to one side so blade physically seats on the outside of the rear wheels.)) i need to get a U-joint on cylinder end, or it would be very easy for cylinder portion to "twist" and in that pull the hyd hoses and wiring connected to each hyd cylinder. the piston ends (aka ball ends) i am still deciding if i want balls or U-joints. ball ends will not a 90 degree bend like a u-joint, but will allow much easier twisting/rotating/angleing, without stuff binding up. but i would be limited to say a 160 degree cone
getting back on point... it would seem i am going to need to build a full physical model of the dog tail into the computer code. so collision detection can be checked against... collision being, one hyd cylinder hitting into another, to U-joint hang up, to other... and goes further needing to also deal with the physical portion of the remote control as well. other words looking more at a dumb clients, with centralized server setup, with a touch screen table or like being the server. and basic min chips were needed (each remote control, each hyd cylinder) these being dumb clients. just enough to send info of sensors and valves and send/receive data. i am to point i am also edgy of putting in "pressure relief" directly in the dumb client/chips, due to possibility of things binding up, if pressure relief was kicked on. other words, backing up truck and trailer, without any review mirrors, backup camera, or anyone else helping, and never getting out of truck or turning head to be able to look behind ya, ya bound to backup into something fairly quickly. this would be like having pressure relief valve kick in, without knowing any better of what may happen.
=============
so what is out there that could take in for collision detection? most games have some sort of collision coding, so your characters and enemies, etc.. do not walk through walls and like. i would imagine 2D games are no go. along with games based on grids, and mimic a look of 3D. i guess i am looking for a 3D game engine, that can handle direct solids, vs vertices, nerbs, and all the little dots matrices. other words difference between autodesk inventor and solid works vs a good majorty of all other 3D modeling software out there. i guess robot software / simulation software might be something. but real time collision detection vs run and let it go for a few minutes to calculate for only a few instances. will need networking support built into it, that be a big one. i guess i need to take some time searching, but guessing most likely starting from scratch...
post 15 pictures, show a u-join on both ends of each hyd cylinder. i was planning to put one u-joint on the cylinder end, and then a ball on the piston end. that is all good and all... but, the u-joint. i forgot about how a U-joint actually works, more so when ya bend the U-joint near 90 degrees. the two pieces want to act almost like a 4 toothed gear. if i went to adjust the "stewart platform" aka dog tail. a person could easily rotate and angle things enough to destroy the u-joints. example. moving dog tail off to one side. ((adjusting an off set rear blade, all the way to one side so blade physically seats on the outside of the rear wheels.)) i need to get a U-joint on cylinder end, or it would be very easy for cylinder portion to "twist" and in that pull the hyd hoses and wiring connected to each hyd cylinder. the piston ends (aka ball ends) i am still deciding if i want balls or U-joints. ball ends will not a 90 degree bend like a u-joint, but will allow much easier twisting/rotating/angleing, without stuff binding up. but i would be limited to say a 160 degree cone
getting back on point... it would seem i am going to need to build a full physical model of the dog tail into the computer code. so collision detection can be checked against... collision being, one hyd cylinder hitting into another, to U-joint hang up, to other... and goes further needing to also deal with the physical portion of the remote control as well. other words looking more at a dumb clients, with centralized server setup, with a touch screen table or like being the server. and basic min chips were needed (each remote control, each hyd cylinder) these being dumb clients. just enough to send info of sensors and valves and send/receive data. i am to point i am also edgy of putting in "pressure relief" directly in the dumb client/chips, due to possibility of things binding up, if pressure relief was kicked on. other words, backing up truck and trailer, without any review mirrors, backup camera, or anyone else helping, and never getting out of truck or turning head to be able to look behind ya, ya bound to backup into something fairly quickly. this would be like having pressure relief valve kick in, without knowing any better of what may happen.
=============
so what is out there that could take in for collision detection? most games have some sort of collision coding, so your characters and enemies, etc.. do not walk through walls and like. i would imagine 2D games are no go. along with games based on grids, and mimic a look of 3D. i guess i am looking for a 3D game engine, that can handle direct solids, vs vertices, nerbs, and all the little dots matrices. other words difference between autodesk inventor and solid works vs a good majorty of all other 3D modeling software out there. i guess robot software / simulation software might be something. but real time collision detection vs run and let it go for a few minutes to calculate for only a few instances. will need networking support built into it, that be a big one. i guess i need to take some time searching, but guessing most likely starting from scratch...
