I need to build a small robot. :-)
I guess the first goals are:
1: The robot needs to be powered by 12 volts direct current via rails. In spite the direct current label, the power feed must be rectified as the robot may end up "turned around" on the power system or may be coupled to another robot that is "turned around."
2: The robot needs to be able to accept inputs via WiFi. These will include control inputs. Ideally, this would be coupled with a small camera that can send back it's video via WiFi.
3: The part of the robot that controls movement must accept "control settings" as opposed to direct movement commands, then simulate what the actual movement would be based on those commands, and parameters fed to it via WiFi. This would include both forward and reverse movement. This could only be overriden by an "emergency stop" command, either instituted by a user, WiFi command (say, via a panic button on the phone or on a PC), or even an onboard sensory system that would detect an unexected obstacle on the track, which would stop the train as quickly as possible.
4: Some control settings would have to be saved after power down, because re-inputting them each time the robot is turned back on would be a bit of a hassle.
5: The "control settings" would also have to be fed to a fully programmable sound system, so it can play (often customized) sounds according to the actual control settings.
What pieces would I need to do this? Any recommendations? Where would I go to get them? Would they be small enough to at least fit inside a Bachmann F7 in HO? How about one of the "Geeps" or the "Special Duty" locomotives (narrower body)? Could they fit in to 'N' scale units (1:160, smaller bodies coming in at under 1.143cm wide, so internal dimensions <9cm wide?)
Below is my first draft. Feel free to read it. It contains a long detailed list of everything I eventually hope to accomplish. :-) If you think you can do something with it, feel free. It's quite a big job, really. {Blushes}
Also, I don't really have a proper layout. I'd have to get a few more pieces to try to setup and test some of the things below.
In any event, this should be an interesting discussion. :-)
This isn't the only problem. From what I can tell, controlling a model train from a PC is neigh impossible. Controlling a layout requires such a hodgepodge of technology spanning the last sixty years or so as to make building such a system extremely difficult. And the computer's ability to keep track of the locations of everything is fuzzy at best.
Finally, even the few things that can be identified and tracked by DCC is, as previously mentioned, fuzzy at best, and railroad cars can't really be tracked at all.
So here is what I'd like to see happen:
1: A cheap transponder that can use a local location system to squak out it's location when queried. This, of course, requires some means of detecting the location, probably via talking to stationary base stations who's locations would be known. These devices have to be small and able to recieve power from a twelve volt direct current rail. Power should be rectified, as the polarity of the direct current rails can reverse. It's just the nature of model train layouts.
1a: Rail car transponders should be able to uncouple the car from the rest of the train on command. Modern knuckle couplers can be uncoupled only when there is slack in the coupler, so this would end up being a bit of a dialogue between the locomotive and the rail car itself, perhaps via the PC acting as the central dispatcher.
2: Obviously an inexpensive location system's base stations, who's positions are known.
3: A video camera small enough to be mounted in an 'N' scale locomotive cab, or, if I must change scales, at least inside an 'HO' scale cab. They should offer wireless video feeds.
4: A brain. This robot needs a brain that can actually simulate the train. It should be able to offer fine control over a 12 volt DC motor, both forward and reverse; be given handling parameters, such as locomotive horsepower, tractive effort, train weight, track grade, track speed limit, etcetera; and actually simulate driving the train, such that the locomotive revs when it's appropriate to do so and idles when it shouldn't be revving anymore and can even simulate dynamic braking where appropriate. This can also effect steam locomotive models as, particularly the big articulated units of the United States, turned out to be quite fickle beasts that forced the operators to really understand the throttles.
5: The robot locomotive would have to be able to detect control signals and respond to them, within the throttle simulation guidelines mentioned above. Speed limits could be designated either by detected turn radii inclusive-or noted by the layout builder. Speed limits may or may not be some sort of sensor based thing on the layout. It should also be able to detect grade crossings and respond appropriately, as well as detect problems (objects on the track that should not be there) and stop.
6: A locomotive should be able to be handed the train consist and a list switching orders, and be able to execute them by itself. This means it would need to be able to throw switches (turnouts), uncouple and couple cars, and push cars in to and pull them out of sidings, "spotting" them for "loading and unloading."
7: This is PC Software side: The locomotives and computer could work together to map out the builder's layout. Instead of the builder telling the computer what his layout looks like, a robot locomotive could be set to explore it for a while, feeding all information on everything the computer will control track-wise, such as position (including height), switch (turnout) location and orientation, signal towers, grade crossings, sidings, etcetera. The user would then be able to easily modify the layout schematic the exploration creates to tell it how often some places need cars swapped outm and what kinds of cars those are, and how many, thus creating a layout that works more akin to Train Fever than the "I turn throttle to drive train."
8: Finally, all this, and the locomotives will need to be able to accept control inputs from a cell phone or pad or even a PC, so a human can "drive" the train at any moment. It would be nice if the robot could override some user inputs if it detects a rules violation, too. This is actually a primary reason why it needs the cameras - so someone at a stationary control location would see the train's movements from the train's point of view.
9: Each train needs to be easily addressable, so if a user opts to take control of one, they can select it and drive it. This also means that the robots must know when they're part of a set, share input settings across the set, direct user requests to appropriate video feeds to the lead unit, etcetera.
I know it sounds like a lot. But we can break it down in to little bits and pieces. :-) Heck, I wouldn't mind if people on here figured it all out and found a way to market their own versions of it.
But to be honest, I see DCC (Digital Cab Control) as a failure, now that I have the DCC model to play with.
DCC units can sort of work with each other. You can sort of use DCC with analogue equipment? You can sort of automate a train layout? You need special equipment to follow your trains around your layout. You can sort of make wireless train controls? You can sort of detect where a train is at? You can sort of hook up a DCC system to a PC?
DCC decoders can cost more than a PlayStation 4. This means that the decoders themselves cost more than basic home PCs do. And they require highly specialized equipment that is all custom made for the purpose.
It just seems to me we can build robots with off-the-shelf components, or nearly off-the-shelf components, that work better now. And it boggles my mind that nobody has done that yet.
Scratch that - I totally get why they haven't done it.
When you spend twenty years developing very expensive and very highly customized technology to put in to model trains, you fall under the "already invested" fallacy. "I've already invested all this time and money developing these products. There's no point in changing it now!" It's the same reason someone who's already waited forty five minutes for a bus that's supposed to arrive every fifteen minutes will continue to wait. "I've already waited forty five minutes. What's another five minutes?"
Same thing here. "I've invested millions developing and maintaining this system. Sure, it's clunky. Sure it drives rivet counters insane. But it's the best I can do with what I got, and there's really no point in developing a cheaper, simpler system now."
The problem here is, in business, if someone does figure out that, you know, those little tiny drones that are smaller than an N-Scale locomotive and can be controlled by a cell phone pretty much makes Digital Cab Control obsolete ... and builds a cheaper, easier alternative to DCC.
Maybe you can help me build it. Or maybe I can inspire someone else to make the cheaper, newer alternative to it. Either way, there's got to be a better way! :-)