Notifications
Clear all
2021-12-13 4:54 pm
@will @robotbuilder "reverse the direction of the train before it enters a shed or exits the turn table." this is correct - the 180 degree turn solves that. shall I start from the bottom and copy all of the bits and pieces out on the script? Going to create a new version.
Yes, please put all of the pieces in place and then post it here so that we can all start again with the same version.
Anything seems possible when you don't know what you're talking about.
kobusven95 reacted
2021-12-13 4:55 pm
@will "I expect you'll eventually need to change that BYJ stepper motor for something faster like a NEMA." does not rely need to, as the speed is OK - remember if it is too fast, it becomes unrealistic.
Got it 🙂
Anything seems possible when you don't know what you're talking about.
kobusven95 reacted
Topic starter
2021-12-13 5:28 pm
@will I will post it tomorrow afternoon. Busy during the day with a course, for this week.
2021-12-13 5:54 pm
Ok, don't feel rushed 🙂
Anything seems possible when you don't know what you're talking about.
kobusven95 reacted
Topic starter
2021-12-14 3:25 pm
I have changed the script as per attached. I am not sure about the stepper motor part - that is going to void a lot of what has been done by Will?
Topic starter
2021-12-14 3:30 pm
Topic starter
2021-12-14 3:51 pm
2021-12-14 4:57 pm
Anything seems possible when you don't know what you're talking about.
2021-12-14 5:16 pm
Looks cool so far 🙂
What seems to be acting odd are the following:
The amber LED's stays on all the time, although the setting "LOW' is.
What pin numbers are they (we can't tell the LED colour from the code) ?
What I have picked up though is that both the IRA sensors act as though they input receive. I have turned the sensitivity off but then it does not respond at all. (Perhaps faulty IRA sensors?)
They will also react to the light in the room, you may have to make "tunnels" for the receivers and point them at the transmitters.
The problem is with this code, in the setup section: (It is read once at startup to confirm that there are NOT a locomotive on the bridge at startup.) (By the way - if there is one, I thought of displaying a warning message?)
Actually that code is in the main loop() and is executed avert time trough the loop.
Maybe try inserting a Serial.println() to print out the sensor values received (add delay(1000) with that command to slow down enough to be readable).
By the way, I was looking at the array of shedSteps and index 1 has 180 whereas the step1 value is is set to 15, so I may have fouled up the array by copying the wrong value. Please fix that if required.
Similarly, the shed positions don't seem to be ordered as I would have expected. As listed now, the first 4 sheds appear to radiate clockwise out from 0 to 105 degrees. I expected that shed angles for 5, 6, 7 and 8 to continue that pattern of clockwise progression but skip the centre portion and end with 8 being the same angle as 1 but in the opposite direction; 7 being the same as 2 widdershins, and so on.
Instead, from the deg5-deg8 it appears that shed 5 is slightly south of WEST, 6 is 15 degrees farther south, 7 is 30 degrees south of 5 and 8 his 5 degrees west of south. Was that intentional ?
Anything seems possible when you don't know what you're talking about.
2021-12-14 5:47 pm
I will leave it to you Will. I can't work on such a messy design process it just drives me crazy. Jumping all over the place with different versions of different pieces. There is no overall coherence in the process. This thread will be going back and forth for a long time as it has done so far.
One of the confusions for me is the talk in terms of shed steps not shed numbers with no reference to the code I posted on moving the stepper motor to a specific shed number. Clearly I don't get the design criteria. When I looked at the ModSet0v3.ino I gave up thinking about it.
2021-12-14 6:36 pm
I will leave it to you Will. I can't work on such a messy design process it just drives me crazy. Jumping all over the place with different versions of different pieces. There is no overall coherence in the process. This thread will be going back and forth for a long time as it has done so far.
I agree that it has been a messy process so far and that's why I asked to get the most current version of the sketch so that we could try to make it a team approach wherein we would try to divide the work by assigning tasks. The goal is to break what's left into small, well defined separate tasks and complete them independently and then offer the results to the team for comments and eventual merging into the sketch.
One of the confusions for me is the talk in terms of shed steps not shed numbers with no reference to the code I posted on moving the stepper motor to a specific shed number. Clearly I don't get the design criteria. When I looked at the ModSet0v3.ino I gave up thinking about it.
I don't know why that wasn't integrated.
As for shed numbers, shed steps and shed angles, they all represent the same thing which is the location of the storage sheds around the circle. Sort of the same way that 90 degrees, EAST and sunrise all represent the same thing. I am confused as well because the sheds don't seem to be in order and shed order doesn't appear to be symmetric (see my last post).
I hope you'll reconsider. I think part of the reason that this is all higgledy-piggledy is that kobusven95 doesn't have a lot of experience and wrote the code in the simplest form for him. And, you have to agree that he did a pretty reasonable job of it and went for the easiest parts first, displays and keypad - just the way he should.
The harder parts he shuffled off, just building in some "place holders" for eventual development after the easy things were developed and tested (just as he was doing). Examples are StepMot(step5).
The result was a haystack of code, just like you'd expect, but it could be tested and the hazy parts were "future enhancements" waiting to happen. All I did so far was try to collect the common elements into subs and reduce the loop() to a minimum size. This had the added benefit of reducing the body of code to a smaller set of understandable parts.
So, I think he's done pretty well for not being an experienced coder. The problem we're all having now is that the requirements and specifications are all in his head and he probably hasn't bothered to lock them down yet because he hasn't had to do so. An example is his discussion of shed locations being flexible because the system will allow him to put the sheds wherever he needs to to clear each other, so he's not been forced to choose between steps and angles.
But, we can accommodate that by just supplying an array of angles representing the offsets from zero degrees (maybe NORTH) and work the code for moving the bridge based on the contents of that array. Or, we could make an array of step counts and use that for the code to move the bridge from its current location to its new location.
So, I'm sure that your experience would easily allow you to work with either data in an array (i.e. step count or angle) without any pressure from undefined or loose ends. If the code is built to use degrees and the eventual decision is that steps would be better for the final resulting hardware, it's just a question of replacing the array with the corresponding values for the other base set. That can be done at any time before, during and after the completion of the sketch without any change required to the code that does the turn.
That's why I'm hoping you'll reconsider, now that we have a good start on the "shell" we should be able to work on new parts by agreeing on a suitable base definition and statement of what it has to do.
Anything seems possible when you don't know what you're talking about.
kobusven95 reacted
2021-12-14 6:59 pm
I checked the original sketch and I definitely made a bad entry in the shedSteps array.
int shedSteps[10] = {0,180,45,75,105,-285,-255,-225,-195,180}; // Array of steps to sheds
Should be
int shedSteps[10] = {0,15,45,75,105,-285,-255,-225,-195,180}; // Array of steps to sheds
where shedSteps[1] = 15 and not 180.
Anything seems possible when you don't know what you're talking about.
kobusven95 reacted
2021-12-14 8:21 pm
As for shed numbers, shed steps and shed angles, they all represent the same thing which is the location of the storage sheds around the circle.
There is a difference between move to shed 9 automatically and move 200 steps left (or right) manually by selecting the move 200 steps (or degrees) button.
I think part of the reason that this is all higgledy-piggledy is that kobusven95 doesn't have a lot of experience and wrote the code in the simplest form for him. And, you have to agree that he did a pretty reasonable job of it and went for the easiest parts first, displays and keypad - just the way he should.
I wondered if his code was based on an actual project on the internet?
I looked at a few examples on the internet to try and get an idea of what might be required. In one example a hall effect sensor is used to reset the stepper motor start point. The other thing I noticed is when the 28BYJ-48 stepper motor was used it was geared to have more torque. Also you cannot have any slack in the system if you want to line up the tracks accurately.
An example is his discussion of shed locations being flexible because the system will allow him to put the sheds wherever he needs to to clear each other, so he's not been forced to choose between steps and angles.
Steps or angles same thing but different from shed numbers. The example I gave you can assign an "angle" (measured in steps) to each numbered shed. Press button 8 and it turns to shed 8. You do not press a button to move x steps.
That's why I'm hoping you'll reconsider, now that we have a good start on the "shell" we should be able to work on new parts by agreeing on a suitable base definition and statement of what it has to do.
There are three main modules that I can see.
Read the keypad.
Display stuff on a screen.
Rotate turn table to shed number entered with keypad.
It is the exact behavior required for any keypress that needs to be stated. I assumed an automatic turn to a shed NUMBER not a turn X STEPS left or right. I don't see how assigning number of steps to a shed works as it depends where you started. You could determine that manually in which case just have a turn left and turn right button.
A similar internet example. The trains are rotated an backed into the sheds.
2021-12-14 8:59 pm
I see the shed positions as degrees from NORTH or steps from 0 (where zero is oriented to point NORTH). So rotating from shed 1 to shed 2 means changing from (current step angle) 15 to new step angle 45. Or (using step counts where 15 degrees = 83 steps and 45 degrees = 256 steps) moving from position 83 to position 256.
I agree with the need for precision in order to align the tracks precisely. It may be required to re-home the bridge occasionally or to use some kind of self-alignment to stop the bridge at exactly the right position. I don't know what width the train's track rail is, nor how long the bridge is. Given those two pieces of information, we could calculate the precision required for rail alignment.
More torque may be required later depending on the weight of the engine and the inherent friction in the bridge axle. That's why I suggested that you use the value stepsPerRevolution instead of the naked count from the stepper data sheet. If it needs to change later to reflect a change of stepper, or of gearing or even a belt drive, it's only single change to the code.
Because the "Stepper" class available as a default in the Arduino libraries doesn't keep track of where it is, we will definitely need to add a (global) variable called "position" or "currPosition" or some other suitablele name and maintain it in the code.
I can see needing the following parts (based on the information available now). Let's assume, for now, that we'll be specifying the bridge locations in the array as degrees clockwise from NORTH, where NORTH is the direction of shed 0.
- a sub "void rotateBridge(toAngle);" to rotate the bridge to a new direction toAngle. It will also have to update the position pointer to the current step count around the circle from NORTH. This is as you stated in your post above.
- a sub "void homeSystem();" which will need to move the stepper slowly in either direction until some sensor is triggered to indicate that it's in position. This could be optical, IR, magnetic or mechanical. When complete, it will set the position variable to zero which will then become the base for locating all otter sheds.
I believe that the existing code fully satisfies the requirement of your module displaying stuff on the screen (as far as information we have now).
The existing code does not provide a robust base for your module requirement for accurately repositioning the bridge (it currently has more of a place holder).
The existing code also does not provide any homing capability all, not even a place holder.
Only kobusven95 can answer to what future functionality may be required, although there are hints as he's talking about I/R sensors to detect if a train is present.
Anything seems possible when you don't know what you're talking about.
2021-12-14 9:19 pm
Anything seems possible when you don't know what you're talking about.