Started building so i thought i would start a thread. Got most of the bar bits together and the main steer axis. Yoke is Aprilla RS. Aluminium box section is temporary for now.
(https://lh4.googleusercontent.com/-vOdCrb1onME/VMN9npOD8xI/AAAAAAAAAEE/cWA8TpkqoM8/w1033-h580-no/WP_20150124_001.jpg)
ended up making a switch housing from alloy billet, all done on the drill press.
Throttle pulley and potentiometer are hidden in the fork stanchion clamp with fake fork tops from aluminium.
(https://lh3.googleusercontent.com/-reNfenATgr4/VMN9r_eBwPI/AAAAAAAAAEU/R6TFJ9h5HOg/w1033-h580-no/WP_20150124_003.jpg)
The steering spindle should allow for drive pulleys and strain gauges to hopefully develop torque steer and force feedback. After a recent discussion thread i am thinking of adding a engine rpm linked vibration motor in the space that used to house the steering lock as this could be quite straight forward to do and i already have the electrical signals as they are the same as the ones that drive my rev counter.
I was hoping to put off the horizontal roll axis spindle for a while as it will need a bit of machining for the raked 'gimbal' attachment but i now see that i need to get on with this bit next.
Got most of the hydraulic bits but need to make some adapters before i can assemble, hydraulic connections seem to have no real standards with a vast mix of thread diameters and pitches >:(
Just a start... lots to do :)
Just to add, really pleased with how nice this 'feels' already. The mass of the bars with a smooth turning action just feel so right :)
All nice and tidy mate.. looks good 8) just need some Renthal racing grips now ;D
Coming together well with some nice touches in there already fella
Really clean build H. Very nice. What did you decide to use for brake and clutch signal in the end?
Keep it up buddy its cool
DD
Managed to scrounge up a couple of old 100bar pressure transducers - so the hydraulic adapters between the 10mm bike fittings and 12mm landy clutch slaves are going to incorporate a G1/4' pressure tapping which should be quite neat. Have not checked the transducers are working yet so hope they are ok.
As a fall back if the transducers are no good i will use the simple load cell scheme on the hydraulic cylinder, still sketching up the conversion of the cylinders to simulate the braking load points but the piston and cylinder design should make this quite simple as its already designed to take a rod in compression that would normally operate the clutch arm.
Sounds like a good plan. Its how I will offer the higher priced systems but the lower priced will have just potentiometers for all analog axis. Im just writing my business proposal for Leo Bodnar that he asked for and hoping to get him in on the steering FFB as he is the bollocks when it comes to steering systems.
I think that with the cheap hydraulic parts you can buy it should still be affordable, I am looking into other transducers as I have found some I THINK might work but not gonna lay my head on the chopping block yet lol.
DD
If you can find a cheap viable transducer that would be great. I'm trying to build in the flexibility to try different ideas with this rig. It will be a WIP for quite a while i think ;)
I know that feeling. Ive been building my systems for 5 years now and change them every time lol. Its hard making a system that is at the same price bracket or around that of a good steering wheel system. I dont think I can retail for less than £350 to be honest as so much more is involved than a wheel system. People dont realize the cost of NEW electronics and parts. I cant retail used bike parts lol. But I sorta got a few tricks up my sleeve for wheel set owners.............watch the next episode lol.
DD
Quote from: h106frp on January 24, 2015, 05:02:43 PM
Managed to scrounge up a couple of old 100bar pressure transducers - so the hydraulic adapters between the 10mm bike fittings and 12mm landy clutch slaves are going to incorporate a G1/4' pressure tapping which should be quite neat. Have not checked the transducers are working yet so hope they are ok.
As a fall back if the transducers are no good i will use the simple load cell scheme on the hydraulic cylinder, still sketching up the conversion of the cylinders to simulate the braking load points but the piston and cylinder design should make this quite simple as its already designed to take a rod in compression that would normally operate the clutch arm.
Would be very interesting to compare the output of the two sensors in terms of precision, noise, response time etc.
MaX.
The mark up on new parts by the time they reach Europe does make them expensive, when you get going and start buying commercial volumes of stock do you think you will be buying items direct from suppliers and selling them on from your site? I'm mainly thinking transducers for force/pressure/displacement. I like the concept of the hall effect potentiometers but only buying 2 or 3 makes them expensive (about 3* the cost of conventional items), this may be balanced out by the vastly extended life span and low noise/precision of these devices though and could be an option/warranty consideration for a commercial device.
For DIY building, the only real expense for the hydraulics is the transducer, using the 'bathroom scale' device and shopping around its probably about £50 for the brake unit complete, pressure transducers alone (in Europe) as this much alone :(. Not cheap, but alongside the throttle probably the most important item for realistic control, its hard to judge how the sim bike is responding to displacement (joystick) braking.
Thanks for the links to Leo's site, the BU0836A looks reasonable value for a properly laid out board plug and play solution, a review of the software side of this controller would be useful as he does not give much detail on his site. I will probably use this for the conventional 'joystick' inputs and run the GPB roll and steer signal through my own board alongside the instrument cluster signals.
The roll axis force feedback could be quite simple for my desk mount setup as you do not have space and weight concerns. The steer axis will need a bit of jiggling to fit gearing and the most compact/low weight motor set-up. I want to use toothed belts for precision, low noise and durability but you do need quite a bit of space to achieve a reasonable reduction ratio.
Quote from: HornetMaX on January 25, 2015, 10:07:42 AM
Quote from: h106frp on January 24, 2015, 05:02:43 PM
Managed to scrounge up a couple of old 100bar pressure transducers - so the hydraulic adapters between the 10mm bike fittings and 12mm landy clutch slaves are going to incorporate a G1/4' pressure tapping which should be quite neat. Have not checked the transducers are working yet so hope they are ok.
As a fall back if the transducers are no good i will use the simple load cell scheme on the hydraulic cylinder, still sketching up the conversion of the cylinders to simulate the braking load points but the piston and cylinder design should make this quite simple as its already designed to take a rod in compression that would normally operate the clutch arm.
Would be very interesting to compare the output of the two sensors in terms of precision, noise, response time etc.
MaX.
Can do once i get set up, they are both internal electronic types and give 0-5v for full range. Noise is not such a concern, the measurement is quasi-static so a simple low pass filter (R-C) would sort this out anyway. The Leo Bodnar board apparently has digital filtering available on the inputs as well but im not sure how this is implemented (review please DD :)
Both units have been fitted with pressure snubbers (to protect against pressure spikes in their original application i guess) and i am trying to work out if i can remove them or open up the port a bit as this will probably slow them down a bit. The actual sensing part is a strain gauge diaphragm so the inherent response time will be much quicker than you can apply the force.
I will have a look at a few vendor sites and see if they quote any typical numbers, the internal constructions will all be very similar so should be good as a guide.
First quote i found...
The standard design of modern pressure transmitters already allows rise times of ≤ 2 ms.
hopefully not too slow ;)
Hi H, yes I will have a complete DIY section. Just because I wish to sell my own controls will not stop me supporting the DIY market, in fact, I am writing the business proposal to Leo Bodnar right at this moment, just popped in to check the forum. I am going to be making components that are very much aimed at the DIY market while still useable in my own systems. This reduces costs and covers both sectors of the market. I am also aiming for the console market for bike games as it is still to do with bike controls and the market is huge.
I will release further detail once I am fully up and running. Its all down to finding the finances right now. I have a full product line to release when I do.
DD
Quote from: h106frp on January 25, 2015, 10:21:43 AM
Quote from: HornetMaX on January 25, 2015, 10:07:42 AM
Quote from: h106frp on January 24, 2015, 05:02:43 PM
Managed to scrounge up a couple of old 100bar pressure transducers - so the hydraulic adapters between the 10mm bike fittings and 12mm landy clutch slaves are going to incorporate a G1/4' pressure tapping which should be quite neat. Have not checked the transducers are working yet so hope they are ok.
As a fall back if the transducers are no good i will use the simple load cell scheme on the hydraulic cylinder, still sketching up the conversion of the cylinders to simulate the braking load points but the piston and cylinder design should make this quite simple as its already designed to take a rod in compression that would normally operate the clutch arm.
Would be very interesting to compare the output of the two sensors in terms of precision, noise, response time etc.
MaX.
First quote i found...
The standard design of modern pressure transmitters already allows rise times of ≤ 2 ms.
Yeah but that is without any filtering I suppose. As soon as you have noise (from the electronics, D/A convertes or from the sensor itself) you start doing filtering and moving averages and your response time suffers.
MaX.
I am not sure yet as I am looking for the right transducers at the mo, but I am sure Leo's boards filter most of the problems out. I am actually asking him in this proposal about his boards and transducers. He is real cool when it comes to making small boards to connect other input devices to his boards.
I will let you know asap.
DD
Quote from: HornetMaX on January 25, 2015, 12:19:04 PM
Quote from: h106frp on January 25, 2015, 10:21:43 AM
Quote from: HornetMaX on January 25, 2015, 10:07:42 AM
Quote from: h106frp on January 24, 2015, 05:02:43 PM
Managed to scrounge up a couple of old 100bar pressure transducers - so the hydraulic adapters between the 10mm bike fittings and 12mm landy clutch slaves are going to incorporate a G1/4' pressure tapping which should be quite neat. Have not checked the transducers are working yet so hope they are ok.
As a fall back if the transducers are no good i will use the simple load cell scheme on the hydraulic cylinder, still sketching up the conversion of the cylinders to simulate the braking load points but the piston and cylinder design should make this quite simple as its already designed to take a rod in compression that would normally operate the clutch arm.
Would be very interesting to compare the output of the two sensors in terms of precision, noise, response time etc.
MaX.
First quote i found...
The standard design of modern pressure transmitters already allows rise times of ≤ 2 ms.
Yeah but that is without any filtering I suppose. As soon as you have noise (from the electronics, D/A convertes or from the sensor itself) you start doing filtering and moving averages and your response time suffers.
MaX.
Having done a lot of this stuff in my real world job i am not too concerned about the noise, the pressures, forces and voltages are high enough to mask out any low level noise issues (often find myself working in microvolt environments). From experience the major source of problems is poor grounding schemes, floating earths etc. This is often overlooked but is probably the most important aspect in getting clean signals. Proper attention to the difference between earthing/drain/grounding and realizing the importance of the various voltage potentials that may exist between what is commonly termed the 'ground' point can often solve what seem puzzling electrical problems.
Warning.... this bit will be of no interest to 99%of readers unless your thinking of building something with multiple power supplies... ::) lol....
Consider the case of USB power from the PC and another source from a wall wart, without checking you cannot guarantee that both will have the same 'ground' potential and currents may circulate between them generating noise voltages. The common one is confusing 0volts with GND or earth, these can easily have a few or maybe even a few hundred volts potential difference and the currents flowing could be significant. Seen equipment destroyed by people attaching grounded mains powered scope probes to the 0 volt point on a piece of equipment without realising the difference in potential - battery powered scopes are better as the low side can 'float' to the equipments ground reference voltage without damage.
Filtering and amplifying should always be the last option and is often not required if other issues are sorted first.
I'm more concerned with the "raw" noise (and precision) of the sensor itself. The electronic noise, as you said, can be dealt with most of the time.
MaX.
The 'raw' noise would most likely be a function of the how noisy the supply voltage is to the transducer, this can be excellent with sensible power supply design, looking at the specs for the budget transducers linked earlier is encouraging;
Brand new pressure transducer. 316 Stainless steel body.
Accuracy: +/-1%FS;
Overload Capacity: 2-4 times;
Working Temperature: -40—+120ºC;
Compensation Temperature: -20—+80ºC;
Protection Class: IP67;
Long-term stability: Less than 0.1%FS/year;
Temperature Effect on Zero: Typical:0.02%FS/ºC; Maximum:0.05%FS/ºC;
Temperature Effect on Sensitivity: Typical:0.02%FS/ºC; Maximum:0.05%FS/ºC;
Shock Resistance: 1000g;
Anti-Shock: ≤+/-0.01%FS(X,Y,Z axes, 200Hz/g);
Response Time: ≤1ms;
I think the quality of modern low cost electronics and laser trimming of bulk components has gone a long way to offering decent relatively low cost instrumentation.
Looks good indeed. Will have to see how the whole behave though (lever + hydraulics + sensor).
A hell of a project you have there man !
MaX.
Roll axis added with raked coupling so i now have my 2 axis motion base.
(https://lh6.googleusercontent.com/-l83dIGdhJf0/VNPTxVaHwWI/AAAAAAAAAGc/Aq9uDGO1atw/w1358-h763-no/WP_20150205_004.jpg)
Also added the bracket for my existing instrument cluster. Due to using a narrow yoke and trimmed bars with full size levers this needs to move with the bars to avoid clearance issues.
(https://lh4.googleusercontent.com/-9pgVkxQ5_rU/VNPTu3G3CDI/AAAAAAAAAGU/8FIrcQ8By_0/w1358-h763-no/WP_20150205_001.jpg)
Motion is very smooth and the rig is well balanced so far. :)
Need to press on with the hydraulic load cylinders now, made a start modifying the cylinders but a bit to do yet.
Really nice clean work H. Its the most professional system I have seen online at all. Fantastic workmanship.
DD
Thanks, the encouragement means a lot coming from the most experienced controller builder on the forum, i just need to stay focused now and get the hydraulics working without drifting off into more features ;D, the cylinders will mount on a small platform attached to the overhanging horizontal shaft and this should help reduce the amount of hose flex i need to accommodate. I think i have a scheme to easily integrate load cell style sensing into the cylinders but it will require machining a few more components.
Took your advice and purchased the Bodnar basic board so this should make the joystick side of the controls a lot simpler to implement.
Need to start looking for a deal on a drive motor for the roll axis, ideally i am looking for a worm drive unit as it should give a much better holding action for this driven axis. Decent units are not cheap though :(
Great fun building though i suspect my heavy engineering background is showing through a bit - you could probably hang a real bike off the front of the rig without too much worry. ::)
Recommend the lightweight pillow block bearings for anyone building , they are cheap, easy to implement , sealed units with grub screws to hold the shaft and run really smooth.
Well thanks for the compliment too m8. I am waiting for a reply from Leo on bike only BU boards with 2 load cell connections on the board and a few other things.
I OVER OVER engineer everything then reduce it, that way it wont break but gets lighter lol.
DD
Looks great! Looking forward to seeing it in action with the rev counter etc good stuff.
Fuel gauge work too?
Edit: oh its a temp gauge lol. Couldnt see on my phone..
Quote from: BOBR6 84 on February 05, 2015, 11:58:31 PM
Looks great! Looking forward to seeing it in action with the rev counter etc good stuff.
Fuel gauge work too?
Edit: oh its a temp gauge lol. Couldnt see on my phone..
All the instruments work, it was the first bit that got me started :) Linked before but i suppose it really belongs here now; Its a standard RVF cluster.
https://www.youtube.com/v/fJhcySBcHCk&feature
It has rev counter,coolant temp, shift light, flashing pit/limiter light and ECU (traction/wheelie) indicator light and gear position.
It would be easiest just to add a small LCD for extra info like fuel or timing info.
The other needle gauge is just testing the bike lean angle signal that will be needed for servo drive.
@DD Be good to have 2 or even 3 load cell amps 2*brake and clutch. I can do the circuitry easy but only onto stripboard so not as compact as Leos designs and he has the USB joystick software side sorted already so saves a lot of work. Be neat if it was a daughter board that could plug straight into the header on the basic board :)
Yeah I did not want a load cell for clutch. He has load cell accelerators for £9.99 that wire between the load cell and the analog inputs on the boards already. I am looking for a board that is complete just for bikes. I also want in on next gen consoles and older ones too. I can do it with my clamp-on steering wheel systems that plug into the pedal ports but I want pure stand alone boards for all, I,m greedy lol.
I'm building controls for a University in Malaysia as they are building a full motion system and want my help so maybe you could help with the dash side of things? I have not done anything with dashes so would be good to chat to you about it some time. Its an important step for me as it is something that will be used for studying motorcycle riding behavior and publish worldwide. I think your dash setup might be interesting for them too if your up for it. Let me know.
Do you Skype? I,m allan.beaton63 if you do.
DD
Quote from: h106frp on February 06, 2015, 12:25:31 AM
It has rev counter,coolant temp, shift light, flashing pit/limiter light and ECU (traction/wheelie) indicator light and gear position.
Too bad we don't have the ECU traction/wheelie information in the plugin interface :(
MaX.
Thanks, wondered why i was struggling to get sense from;
int m_iECUMode; /* 0 = engine mapping; 1 = traction control; 2 = engine braking */
char m_szEngineMapping[3];
int m_iTractionControl;
Could you explain how these fields are defined as its not very clear? I had initially assumed 'traction control' flag indicated ECU active
LED and software functions are ready for when this gets sorted though, is it on the suggestions list? it would seem important for telemetry analysis to know when the ECU overrides rider input.
Pit lane limiting also seems a bit odd, i cannot quite understand how this has been implemented. I press the in game key but i do not seem to activate the limiter/indicator (normal game controls and on screen dash). Tried in pit lane and on track :(
Rev limiter/shift light work as expected though :)
Quote from: h106frp on February 06, 2015, 08:03:27 AM
Thanks, wondered why i was struggling to get sense from;
int m_iECUMode; /* 0 = engine mapping; 1 = traction control; 2 = engine braking */
char m_szEngineMapping[3];
int m_iTractionControl;
Could you explain how these fields are defined as its not very clear? I had initially assumed 'traction control' flag indicated ECU active
They are essentially information for the dash of the bike, to change the settings of map, TC and EB while riding.
They
don't tell you if TC or EB are currently "overriding" the rider input.
Quote from: h106frp on February 06, 2015, 08:03:27 AM
LED and software functions are ready for when this gets sorted though, is it on the suggestions list? it would seem important for telemetry analysis to know when the ECU overrides rider input.
I've already requested it, but ...
Quote from: h106frp on February 06, 2015, 08:03:27 AM
Pit lane limiting also seems a bit odd, i cannot quite understand how this has been implemented. I press the in game key but i do not seem to activate the limiter/indicator (normal game controls and on screen dash). Tried in pit lane and on track :(
IIRC, it doesn't work in testing sessions, only during race events (practice, quali, warm-up, race). Don't know why though.
MaX.
Thanks, that clears thing up :)
@DD
Always be happy to help with some of the concepts for simulating real life signals to drive real instruments, but i suspect that a university rig will be using industrial style control interfaces and the code/controller will be written in something like NI Labview (the most popular system not non programmers ;) ::)) so our GPB experience probably will not help that much.
For a custom rig i also suspect they might go for a very modern CANBUS (serial data) type instrument cluster as this is easily controlled directly from their simulator interface without any need for analogue conversion circuits.
They will probably develop a tool similar to MaX telemetry to study the rider behavior.
They might be a University but their initial concept was wrong and I am having to set things straight as they are NOT real life riders (BIG MINUS) but they are dedicated. I think that they are on a limited budget so maybe not got so much high end electronics, I am still waiting on that info. I am just proud that they approched me of all the people in the world that must know more than me lol. I just got better BS lol. Anywho, I think its a chance to be involved with a more professional approach team in that its not just for fun, its a serious study and could lead to some really cool concepts with many minds working together.
I will post more once I make all my info in a form I can post here.
This thread is really taking shape in the form of a serious control system for bikes and not just a gaming toy. Hats off to you all for the knowledge and sharing there of. I think we are on the right tracks at last.
DD
The NI/Labview route is by far the easiest/most flexible way of doing this sort of thing. Most devices will already have drivers written and both the software and hardware are heavily subsidized for educational use.
Might have got a bit carried away with the roll axis motor ::) It was a 'bargain' from one of those bankrupt stock type warehouses. Bit bigger than expected :o Trying to convince myself that it was a good purchase....
(https://lh4.googleusercontent.com/-s_0sy12-_B0/VNufTbDVHfI/AAAAAAAAAHI/6XMzgw0CO0U/w447-h796-no/WP_20150211_001.jpg)
Output shaft is 25mm dia so i suspect it may have a 'bit' of torque available ;D
I can see that thing bending a frame if it aint strong lol, fuggin 25mm can take weight bro. Hey you industrial power supply at your house to run it lol
DD
I think you could probably drive a sit on frame with this thing!
Power is not as bad as it seems as i have gone 24volt to keep the amps to something that does not need welding cable to connect it up. Biggest concern is keeping it under control and safe, be a bit worrying if it just ended up spinning round! Limit stops/switches and e-stop are high on the list of tasks before i even think of powering it up. It should do 120 degree sweep (lock to lock) in about 0.5 seconds if you let it 8)
It also weighs a ton :(
The safety of these things is a big concern. That thing can kill, seriously !
MaX.
Good advice to anyone experimenting with higher toque motors and i will certainly be removing the bar vertical axis assembly for testing and set-up, the idea of the handlebars flying round at 180rpm is very sobering.
It is a bit concerning dude. I could think of some nasty shit with that thing. It is the sort of thing needed though. If you think how quickly a pro goes from fully cranked over on one side to the totally opposite its gotta be quick if your building it the way I want to do it. I use good quality steel just on my static systems and you CANT break or bend em. I had a dude with 349lb on one time and it didnt even wobble!!!
Looking forward to seeing some SAFE tests and maybe some shows of its force.
DD
What does that do exactly? force feedback?
You lot should put your heads together and jump on a project!!
Its the motor for driving the movement and force feedback BOBP or it could be some perverted thingy majig H is constructing. Can neva tell wiv you lot, but I aint bendin over anywhere near it. lol
DD
lol :D
so.. when the handlebars shake in GPB this rig will do the same??
hehe get the cushions ready ;D
The scheme is to simulate 'normal' bike steering, or at least discover if it is possible. This motor/gbox will rotate the bars to simulate the lean angle of the bike using the output from GPB. The reason for it needing to be fairly powerful is so that the 'rider' cannot influence the lean by bar force, it is only ever driven to the correct angle as calculated by GPB.
Another separate motor/gearbox assembly will be used to provide the 'force feedback' signal computed by GPB for the bars steer angle, the input to the system will be the torque applied to the bars by the rider.
It will also feature hydraulic force sensing brake and clutch.
Thats the plan anyway, i'm sure it will take a bit of development to get right but it's an interesting technical exercise :)
Highsiding here we come.😳
What happens if the signal from GPB is fooked, It might cream you from side to side even if the bike on screen is going striaght lol. Hope Piboso got all that coding right lol
DD
Its a serious concern, on the main roll axis i have fitted a solid stop block to limit the travel to +-60 degrees, this also has limit switches that will stop the servo controller in that direction as well. I will do the same for the steer axis as well.
I will add a bit of code to the control signal send to trap any really crazy stuff that comes from GPB, trapping the peak values in software does suggest that occasional spikes occur on the steer torque axis that are 10x (350Nm reported) the normal magnitudes you would expect, i guess this is just a computational thing though if could possibly explain some of the 'freak' crashes people observe in game. MaX has seen similar with his logger so he might know if they relate to any specific activity in the sim environment.
The intention is also to have a master kill/panic switch on the servo enable line - i was thinking dead mans handle style so that if you let go of the grips it will stop but can't figure an easy but elegant way to do it - a 'push to enable' foot switch might be easier to implement.
Hopefully once the bugs are ironed out it will be reliable and confidence will build :).
Going to concentrate on finishing the hydraulic stuff first though. Latest plan is to have the load cylinders move with the bars - this will mean the hoses and banjo bolts are not flexed so less chance of leaks developing. Wish i had used the alloy cylinders now as the cast ones are fairly heavy but i was concerned about bore wear at the time i ordered them, in hindsight i doubt this will be an issue. Maybe i will upgrade them in the future if the system works out OK.
Just thinking about a kill switch could you use one of those sensor you get on a exercise bike that monitors your heart beat.
No idea how they work or if you could use it.
Nice idea, but probably a bit complex for a safety device.
Just thinking out loud, but trying to get a handle on motor gearing/power/ and torque for a controller.
Referencing consumer items..
From an owners practical tests.....
G27 wheel 3Nm
T500 Wheel 6Nm, 30 cm wheel, 65 watt motor - i guess its quite a high gear ratio 60:1 or so for this torque from a small motor
My smaller steering axis motor is 150 watt and should be 12 to 14Nm at about the equivalent to a 600mm 'wheel' using just the 25:1 gearbox with no extra pulley belt gearing... It is feasible to add another 2:1 on the gearbox output to raise it to about 25Nm but i would rather the response does not get too lethargic.
Be nice to get it all mocked up and see how it feels for real but i need to manufacture an adapter between motor and box first :( then i can get a real feel for the response profile of the bars steer axis :)
So.. it should feel similar to the T500 wheel for force/torque with just the gbox, does anyone have a t500 wheel, and if so, how does it feel for torque? sufficient for gameplay?
Thanks
For the kill switch maybe think about the jet ski kind of thing. A short cord and peg from wrist to a sprung switch, remove your hand from the grip and it dies.
I have a T500 and turn it down for anything but a demo of the FFB, it's a real work out on full but nothing a grown man couldn't overpower.
Looking sweet btw :D
Thanks for that info, measuring up the actual span of the bars at around 500mm i'm probably the equivalent to another 25% better in torque than i first estimated so with your impressions of the T500 i feel a bit more confident with going direct drive from the box which will simplify things :)
I had not considered a lanyard, that may be a very good quick acting solution, thanks.
Quote from: teeds on February 18, 2015, 08:00:25 PM
For the kill switch maybe think about the jet ski kind of thing. A short cord and peg from wrist to a sprung switch, remove your hand from the grip and it dies.
Hi teeds maybe you think something like that ?
(http://img4.hostingpics.net/pics/563945Screenshot20150219062333.png) (http://www.hostingpics.net/viewer.php?id=563945Screenshot20150219062333.png)
The lanyard is not quick enough to stop an injury from happening it has to be far quick response than that. You need a physical limiter switch for rotational direction and speed of rotation. It depends on how the actual framework is designed and the end points of movement. If I had a pic of the framework design and the motion directions I could say more.
DD
Hi DD,
Both axis (will) have large physical travel stops and limit switches, what i am after is a way of making it stop if it has a software 'fit'. The scenario i can see is that something happens in the sim software (where i have no control) to generate an extreme cyclic range of movement - the moving rig contained safely within the physical stops and travelling between servo limits- and i really want to stop the motors as soon as you let go of the bars as with no restraining force the movement could suddenly become more excessive. The lanyard idea seems ideal for this as it physically connects the user action with the kill function.
As for the framework that idea is still evolving ::) its a bit 'make it up as you go along' and waiting until i have sourced all the big bits to decide. I could not really draw it up as i am just using whatever materials come to hand at the moment to keep the costs down ;) Sort of getting there now though and a proper frame may be the best way to sort out the horizontal drive motor mount (it still look huge ::) ) as i suspect this might need to be strong but lightweight.
Got the steer axis motor and box joined together and i am quite pleased with the result. Seems powerful but fairly compact. Hopefully get it 'in-situ' soon and finally get a feel for the bar forces ;D Just hope it works as i am expecting after all this effort.
At the risk of being Cpt. Obvious, 2 trivial things:
- Put a limit on the current that can be delivered to the motor. Ideally, this should be in the hardware/firmware.
- In GPB output plugin, there's an indicator (m_iCrashed) that tells when the rider is no longer on the bike: as soon as this goes to 1, just stop everything.
MaX.
Current is controllable in hardware so i can limit the force but we will probable need to operate with high torque (current) for a convincing steering rig model in torque steer mode as discussed previously. For simple FF mode the torques could be set lower.
I will add software controls, but it is dependent on totally bug free software which will not happen until it been debugged, so i need a solution for this phase at least.
I think the lanyard will work, i can safely limit rig travels, its just that transition from hands on to hitting the e-stop that might cause problems. Its not such an issue with a wheel, it just spins but with bars and levers on 2 axis it could become a bit of a 'flail' and thats why i am being cautious. I am confident that once its built and the software sorted it will be fine and safe - its mainly during testing/development that i have concerns.
The lanyard would be good but I would suggest making it to the right wrist to reduce the amount of movement needed as one to the body will have to much play to be safe, also your throttle wrist is the least likely part of your body you would move away from the system during use.
DD
Got the steer motor and box onto the steer shaft, i think it looks quite 8).
(https://lh4.googleusercontent.com/-eJ_k8M4AOgw/VOijnbcowwI/AAAAAAAAAJ4/7x7-U38GfG8/w1358-h763-no/WP_20150221_001.jpg)
(https://lh6.googleusercontent.com/-fPzg7uiKM0U/VOijprQ0pnI/AAAAAAAAAKA/fQ1LTq960kE/w460-h819-no/WP_20150221_002.jpg)
After a rather 'uncontrolled' ::) experiment (just could not resist) i am now quite happy that this is more than powerful enough for initial tests, but it does need the steer axis to motor base plate sorting before i try anymore powered tests. This thing can 'whip' the bars across just as fast as suspected - looks like it could be lot of fun when its done :D
Balance feels good so far and the load (inertia) on the roll axis shaft is very low :).
After deciding (being informed ::)) that having hydraulic fluid in the house was a bad idea and struggling to fit in all the cylinders/pipes/sensors etc anyway i have revisited the brake sensor concept and remembered DD suggesting fitting something directly into the master cylinder space itself - inspiration :).
Dismantling the brake levers i have found plenty of space in the radial type design and replaced the 12mm diameter pistons with home made load cells using silicon strain sensors. I added a small sprung section to the top of each cell to give a little bit of initial travel made from the original piston parts - it felt odd being solid at the initial lever travel. The wires lead out through the opened out fluid outlet port. Another small spring keeps the radial lever push rod in light contact with the sensor. Rest of the mechanism works as originally intended and retains the adjustable lever reach mechanism.
(https://lh6.googleusercontent.com/-nXDQJ0tc9No/VPeGYkBAp-I/AAAAAAAAAK8/6WBxvx3dAcY/w1358-h763-no/WP_20150304_002.jpg)
Instrumented load cells designed to replace master cylinder piston 12mm dia
Feels great, and has that familiar brake like feel, small initial start and then loading the sensor directly. The sensors are giving about a 10 ohm change for a sensible lever pull so the electronics should be straight forward using a simple bridge and op-amp.
Sorry for being hardware noob, I'm not sure I get it.
Essentially, your "piston" is not moving and you're measuring the strain on it ?
MaX.
That how it works - the fixed load cell replaces the piston and is squashed between the end of the cylinder and the push rod that comes down from the lever. The radial master cylinder and lever seems ideal for this approach. The little pin and spring are fitted into the end of the cell to allow a little lever movement with only the spring rate loading the cell, once this bottoms out all the lever load is applied directly to the top of the load cell - it just allows for a more natural lever action.
It is just a very simple column load cell so its just measuring the compressive strain applied by the push rod - the silicon gauges give about 50* the resistance change for a given strain than the more familiar foil gauge so the electronics are a bit simpler.
OK, thanks.
Sounds very good. GPB even has a "gain" slider, that could be handy to tune the whole thing.
Very promising !
MaX.
Thats pretty clever H. Can you give more info on the silicon strain sensors or a link pretty please. It sounds interesting. I found this site from UK company and has some great free PDF docs on measuring pressure, torque etc so thought I would post the link here
HBM UK Measuring torque correctly 261 page reference book http://www.hbm.com/en/menu/tips-tricks/torque-measurement/reference-book/ (http://www.hbm.com/en/menu/tips-tricks/torque-measurement/reference-book/)
DD
Thanks for the link, i will see if they have any good ideas.
Semi conductor silicon gauges have been around a long time and can be used the same way as conventional foil gauges but with much higher outputs.
http://www.kulite.com/products.asp?p=4-0 (http://www.kulite.com/products.asp?p=4-0) look at bottom link
Bare gauges for adhesive mounting from;
http://www.appmeas.co.uk/index.html (http://www.appmeas.co.uk/index.html)
which are a UK company.
I have considered the simple force sensors again as the forces are much lower in this application method, they are the same diameter as the master cylinder housing and after a bit of reading up the output can be reasonably linearized with an external op-amp. The sensor could be placed in the bottom of the master cylinder bore and loaded in a similar way with a simple soft faced 'plug'. Could be a very simple option to explore in the future.
(http://www.technobotsonline.com/images/detailed/17/09375-1.jpg)
Small general progress update; the steer axis to motor mounting plate is now finished and includes a steering lock limit. Most of my spare time has been spent implementing 2 I2C DACS into my microcontroller for controlling the servo demand and cleaning up my host PC software for better function testing. Next task is a bit of electronics for level shifting the DAC signals to suitable voltages (0 to +5 to +-10volt) for the servo controller and i am going to try the conductive paint method to modify the sweep of my feedback potentiometers to the correct angles.
Thanks for the Links. I need a 3 wire sensor for analog on my boards, +, - and output, so some sensors are no good. I have to wait to get more money to get the different types to play with as I need all I have to start up just my basic systems first. 3D printing aint cheap to start lol.
DD
The simplest way to get a 3 wire output is just use another resistor in series with sensing resistor and use it as a voltage divider, just like a potentiometer. For my load sensor this would gives me about 40mV change from the mean value for a 5V supply.
More graceful to use a half bridge (as above) and an op-amp which allows gain and offset adjustment, simple and cheap :) and it is what i will do for the clutch and brake circuit to interface to leo's board.
Well, a bit of op-amp magic and i have a nice 0-5 volt output force sensitive brake and clutch without any messy hydraulics :) One more step forward! Time to commit some of these circuit to veroboard - time to warm up the iron ;D
Been reading whole 5 pages :o and just ask where is this project now ? i would love to see it in use !
Quote from: poumpouny on June 16, 2017, 08:47:52 AM
Been reading whole 5 pages :o and just ask where is this project now ? i would love to see it in use !
i am Curious, please update the video when you play with your project