Looks good from where I am sitting, now I just need to try and understand everthingy I am looking at
in the words of Pauline Hanson “Please explain!”
What are the actual names of the various components starting from the top to the bottom, please
This would help, certainly be more fun. I haven’t seen how to add comments yet, but it looks like you can add descriptions to nodes.
The next thing might be to add the 4-line (or 2-line) lcd display. Gweimer actually wrote those and added them to XOD.
I’ll describe top to bottom on XOD. Let me know if you can’t download this to play with.
Bike Gears.xodball (22.2 KB)
awesome stuff! i love it!
now to get the motor running and the 28 gears responding to the multiplier of 0.296
Motor only has a maximum of 60rpm
Starting at the top:
-
The 11 boxes with a True or False in them are debug boolean tweak nodes. If you download and deploy the simulator on the Bike Gears.xodball file, you will be able to click on any of those nodes and set a different one of the 4 left (Front gear) ones and one of the 7 right ones (Rear) to True.
-
The single line of text in the debug watch node, at the bottom right, will change accordingly.
-
These boxes will eventually get replaced with 11 switch or digital read nodes attached to the 11 opto-interrupter devices which actually read the gear positions.
-
The 11 “if-else” boxes, conditional nodes, beneath them use that boolean true/false value to select a number to be included in the single, 11 term adder node beneath them. So, since I have the “C” and the “5” boolean tweaks set to true, the C one adds 14 to the sum, and the rear 5 one adds 5 to the sum, making 19, the Gear number. The others, set to False, add a zero.
-
The next row has 3 nodes, each of which gets the Gear number as input. The left one is a “format-number” node which takes the 19 and outputs the string “19”, with nothing after the decimal point since its digits parameter is set to 0.
-
That and all strings go to the 9 input string concatenate node at the bottom left. It is the second input, the first being the string "Gear: ", which is fixed and set in the node itself with the inspector.
-
The add node to the right of that just adds a -1 to the Gear number, making it 0-27 instead of 1 to 28. This is so that the two math nodes beneath it can 1) do a divide by 7, giving a value 0-3, the input needed for the nth-input node beneath it to convert that 0-3 to strings “A” thru “D” which then get concatenated (appended) on to the string to be displayed.
-
The Gear Ratio node is a 29 input nth-input node, which is the lookup table for the gear ratios from your table, for gears 1-28. Entry X0 doesn’t get used; there is no Gear 0.
-
Step 7 part 2) The modulo node, also gets the 0-27 number and divides by 7, but keeps only the remainder, which is a number 0-6. That gets a 1 added to it by the add node to its right resulting in a number 1-7, which gets formatted into a string with 0 digits to the right of the decimal point. So far the string being built has “Gear: 19 C5”
-
The next two (last two) format-number boxes use the looked-up gear ratio from the Gear Ratio lookup table node. The first one displays the looked up value with precision of 2 digits beyond the decimal point.
-
The next format-number box first gets the reciprocal of the looked up gear ratio. Thus 0.029 becomes “34.5” with precision of 1 digit beyond the decimal point.
If you or anyone has a question, you can refer to the above 11 step numbers in your question.
I’m just now learning XOD, so I will leave deep XOD questions to the veterans.
Cheers, mate!
That’s because of internal gearing so the 1 rev per second has enough torque to accelerate you, right?
Actually, it’s because I’m using a 12v windscreen wiper motor from a car, rear ones aren’t designed to wipe a huge area under high wind load, with an old 54 tooth bicycle front sprocket mounted to the motor.
I can control the motor down to to 1rpm, via a 40A motor controller, but the controller only allows it to get to 58.8rpm!
I see.
I looked back at your original gear tables sheet.
The secondary gearing is always in place and we built it in to the lookup table.
I will add another output line for the corresponding motor ratios.
I’ll find some pics of my “gear box” so you can see what I’ve built but that’ll be after work tomorrow.
Front gears are 4 chain rings 24, 36, 46, 52
Rear gears are 44, 34, 22, 20, 18, 16, 14 on a lay shaft with dual 80 tooth pocket rocket sprockets mounted to freewheel adaptors, driving 6 tooth pinions in the end of 1/2 shafts with 20" wheels being the last piece of the puzzle.
I have linear pedals, my own design, that gives me one complete rev of the front gears, with just the extension of my legs. Both legs, one leg, flex toes, every leg movement drives the dual rear wheel drive.
So at 100rpm cadence, I’m only doing 55 strokes per minute
The LCD display will show;
the motor rpm at top Left corner (0-60)
the calculated speed at top Right corner (xxxx.xxx) 'cos thousandth count in records
Cadence rpm Left middle
Actual speed Right middle (xxxx.xxx)Km/M alt every 2.5 secs
Gear # Bottom Left
GPS speed Bottom Right
with real time/date somewhere in there as well
Speed sensing is from IR sensor firing through a hole in front gears, & motor chainring,
And originally from a Reed switch on rear wheels, but that’s not final
Nice! I didn’t get from the pocket rocket sprockets …to the tooth pinions part.
Linear pedals of your own design. Cool!
Independent leg motions? How crazy is that?
Wait, we humans have independent log motions
So there is no required phasing or alternating of leg extensions? Just possible ones?
Sure sounds like an improvement worth sharing. If you haven’t sold it yet, you could probably patent and license it. (A 1-year protective provisional patent filing is cheap ($140).
I look forward to your pics. Glad I may have helped some.
“Optimal” layout is very subjective. I think you did a good job. I try to keep “parts” of a program grouped together. If there are redundant parts, try to make them all look the same; it might take a little more space, but it will be a lot easier to read. With VERY rare exceptions (there might not be any), over-lapping nodes is bad; it makes it hard to see what the nodes are and where wires are going. Try to minimize wires crossing each other or behind nodes. In the patch above, there are some wires going behind nodes, but in general they are not cluttered and easy to follow. One possible exception is the wire passing behind the divide node; the main reason this one is a problem is because it passes right through the pin of the divide node, so it looks like 2 wires connecting to that pin. The concat to watch wire is a little harder to see because concat blocks so much of it; it would be almost impossible to find if you pushed the watch node up against the concat node, but is probably OK as is.
There are bus nodes (to-bus and from-bus) that can sometimes be used to reduce clutter. If you select an existing wire and hit “b”, it will replace the wire with 2 bus nodes and try to label them reasonably. Any bus nodes with the same label will all be linked together (basically joined by invisible wires). This means there can only be one to-bus for each label (only one input value is allowed); there can be any number of from-bus nodes with the same label, and any number of wires coming out of any from-bus. These are most often used to loop a wire back up to a point higher in the program, or to connect a wire to the other side of your patch without cluttering the screen. Note that over-use of bus nodes means you have to search to find where the data is coming from or going to and actually makes a patch harder to read.
That’s the magnet, I guess.
There are multiple free wheel adapters. Why is that? So you don’t have gear inertia?
Each side linear pedals needs a freewheel so the main gears are constantly driving while the leg retracts.
The motor has a freewheel so allow the gears to turn when the motor is off.
The rear gear set has dual freewheels so that the “diff” isn’t just locked