Misadventures in Tilt

[Hod Carrier]

Anyone who has been following the OcTRAINber WIP thread over on BMR's Flickr pages may recall that I had been looking at the possibility of using Mindstorms as a way of providing active tilt for a LEGO train. Most LEGO tilting trains use a mechanical system to provide a form of passive tilt, but I wanted to produce something that would tilt proportionally to the cornering speed, as real tilting trains do.

The original intention had been to use the Gyro sensor to measure the rate of turning for each vehicle and to use the output from that as the basis for a tilt program. Simple!! Just a case of knocking up a prototype, testing and then hey presto, right? Well, sadly this was merely the first chapter in what's become a bit of a saga which showed me that I was not going to meet the contest deadline. Although the Gyro sensor was in stock the servo motors were not, so it was the middle of October before I could even make any sort of start. Then I discovered that my first design for a tilt mechanism was totally off whack, so I had to quickly make a redesign and order more parts delaying me further.

This is tilt pack v2.0 which is now a lot stronger and more stable. Initial testing showed that the power level had to be carefully set. Too low and the tilt reacted too slowly, too high and it threw the test car off the track.

(Click, it's a video.)

Problems now occurred with the choice of sensor. Running in one direction, the Gyro sensor worked well and prompted tilt at just the right times, but reverse the train and the car tilts the wrong way because of the way in which the sensor measures and expresses the rate of turning.

After this, I decided to see what other sensor I could use. Having had some success with colour sensors I decided to give this a go. Using the Colour sensor the train could measure it's speed and even discern it's direction of travel, then it could take instructions when to tilt and in which direction, all using coloured tiles in the track. A quick basic program showed that the concept at least worked relatively well but it wasn't actually active tilt as such a system could not react to changes in the rate of turning.

A trawl through the internet turned up third party supplier HiTechnic and their Accelerometer sensor, which looked highly promising. Cue another delay while I waited for them to arrive from Prague, and then on with the show. Playing with these showed that these would be very useful at centring the car automatically, something that I had been concerned about for a while, but that was about all I could achieve. These sensors would be great for a balancing robot of some sort, but they really only seem to detect acceleration due to gravity and, therefore, tilt. Trying to get any meaningful results out of them for measuring cornering forces proved to be fruitless.

(Click, it's another video.)

So where am I now? Well I think I'm going to put true active tilt on the back-burner for a while until I can crack how to use the sensors I have available to achieve this. In the meantime I've gone back to using the Colour sensor to try and at least get a workable proportional tilt system. Most of the work going on at the moment is based around the coding to get the program to work as I want. It's been more challenging than I expected, as the train I intended to build has three cars, and getting the code right so that it operates correctly in both directions while tilting each car at the right time and in the correct sequence is proving harder than originally envisaged. However, I am chipping away at it. While I can't enter this into the OcTRAINber contest I will keep working on this and will report back here.

Edited November 14, 2019 by Hod Carrier

[LEGO Train 12 Volts]

Wonderful and ambitious project (it deserves the first prize once completed) and it would be the third year in a row that you would win.

Too bad that having so little time and so many problems to solve, you failed to meet the deadline

I hope to see your project complete as soon as possible ... for me you are always among the best! 

[zephyr1934]

That is insane!

[Paperinik77pk]

Hi @Hod Carrier, this is a great project, and surely it's a mess to make all things to work properly together!!!

I don't know very well the Mindstorms parts - and I'm really interested to see this technology applied to trains!!!

I have some questions for you regarding the sensors/software:

• Normally tilting trains are double-headed (I think about the classic Italian "Pendolino") - is your creation a stand-alone vehicle or is it part of a bigger train?
• Is it possible to attach two or more gyro-sensors on the same controller, and choose by software the dominant one (e.g. according to direction)?
• is it possible to drive one or more actuator (motor) starting from what is sensed by the gyros?

I am wondering how a long train could work and if it can be driven to lean each component gradually while approaching a curve (according to Gyro sensors readings).

Ciao!

Davide

 

 

Edited November 15, 2019 by Paperinik77pk

[Hod Carrier]

@zephyr1934  I think that "insane" is precisely the right word to use. If I'd had any idea of the complexity of this project or that I'd have so many delays and setbacks I probably would have built something else entirely.

@LEGO Train 12 Volts  Thank you for your endorsement, but I can't possibly win this contest every year. That just wouldn't be fair on everyone else. But I shall persevere with this idea and something will end up getting built off the back of it.

@Paperinik77pk  The EV3 brick supports up to four sensors and four motors, but theoretically you could have a train of any length provided that you had enough EV3 bricks (and enough money to pay for all the hardware). The train I am proposing to build will be three cars long which is fine for just a single EV3 brick.

The original concept that I was working on would have had one Gyro sensor and one servo motor per car linked to the EV3 brick. The EV3 brick would then run multiple strands of code simultaneously (one strand per car) where the input from the Gyro sensor would be compared to a threshold level, a degree of tilt calculated and the output fed to the servo motor to initiate tilt. As the rate of turning increased and decreased so the angle of tilt would increase and decrease. Each car would then be autonomous and able to tilt independently according to the rate of turning being experienced at any time, so there would be no need to designate which sensor should be dominant and which submissive.

Conceptually this was quite simple but the way in which this had to be expressed in the Mindstorms code was very complex and hard to get to work correctly. I could easily get the train to recognise whether or not the threshold level had been exceeded and to tilt to a predetermined angle and back again, but when I tried to get it to implement a mathematical solution to working out it's own tilt angles I found it was highly unreliable. I've yet to discover if this was a problem with the way I'd written the code or if there were issues with the way in which the sensor was feeding data to the EV3 brick. It may simply be that I'm pushing the capabilities of the Gyro sensor too far due to the speed of cornering and the need for it to react quickly. And then there was the problem with reversing the train and the car suddenly tilting the wrong way. Either way, I've had to put this problem aside as it was threatening to absorb all my spare time.

I did want to have a nice gradual tilt action, but unfortunately I have discovered that slow tilt transitions are not going to be possible. The servo motors are programmed to move only to a certain number of degrees as set by the tilt program, so the output shaft never completes a full revolution (for the purposes of the programming, and to allow for the gearing in the tilt pack, the maximum permitted output angle is around 90 degrees in each direction). Because of this, altering the motor power variable does not achieve the effect I wanted. Turned down to 5% the tilt pack seems very slow to react and jerky, but turned right up to 100% it would throw the test car right off the track and onto it's side, even when not moving. Consequently I've elected to set the motor power to 30% because it gives a crisp response without derailments.

As I mentioned above, I've had to shelve any plans to use either the Gyro sensor or the HiTechnic Accelerometers and go back to using Colour sensors. Right now I'm at the point of testing new code that will hopefully pave the way to add more cars to the train. The problem at the moment is working out how to make the EV3 brick do more than one action at a time, but I think I have a solution. I also need to work out how to implement a second colour sensor into the train so that it can run in both directions and work out it's actions accordingly. The positioning of what I'm calling the tilt command tiles in the track that instruct the train to tilt and then re-centre the train as it enters and leaves a bend means that I shall need to place the colour sensor at the front of the train. To reverse the train a second colour sensor will be required at the opposite end of the train, but it will be necessary for the EV3 brick to know which colour sensor it should be taking commands from and which to ignore. If I can crack these problems I shall be able to build a working tilting train, although it won't be the true active tilting train that I had set out to build. That goal will take longer to achieve.

[Roadmonkeytj]

so just thinking out loud as I have never "played" with the gyro sensor ... I read your response to Paperinik77pk and I originally was thinking the same way he did.  Now I'm wondering if two gyro sensors one in the head engine and one in the tail engine facing opposite (since your train is so short) have a code that is determined by travel direction as to which sensor it uses for data collection. 

Keep the EV3 in the center car and have it run a servo for each car?

 

[Phil B]

23 minutes ago, Hod Carrier said:

<snip>

As I mentioned above, I've had to shelve any plans to use either the Gyro sensor or the HiTechnic Accelerometers and go back to using Colour sensors. Right now I'm at the point of testing new code that will hopefully pave the way to add more cars to the train. The problem at the moment is working out how to make the EV3 brick do more than one action at a time, but I think I have a solution. I also need to work out how to implement a second colour sensor into the train so that it can run in both directions and work out it's actions accordingly. The positioning of what I'm calling the tilt command tiles in the track that instruct the train to tilt and then re-centre the train as it enters and leaves a bend means that I shall need to place the colour sensor at the front of the train. To reverse the train a second colour sensor will be required at the opposite end of the train, but it will be necessary for the EV3 brick to know which colour sensor it should be taking commands from and which to ignore. If I can crack these problems I shall be able to build a working tilting train, although it won't be the true active tilting train that I had set out to build. That goal will take longer to achieve.

Can't you use a single gyro-sensor to measure direction of acceleration/movement, and thus determine which color sensor to use? If you use the Rate measuring feature to detect a change in speed/direction, wouldn't that help? You need to somehow know that you are moving backwards though, and not just slowing down.

Alternatively, you could have special calibration tiles on your track, and the sequence in which you encounter them tells your train which direction it is moving in.

Interesting challenge!

[Hod Carrier]

55 minutes ago, Roadmonkeytj said:

so just thinking out loud as I have never "played" with the gyro sensor ... I read your response to Paperinik77pk and I originally was thinking the same way he did.  Now I'm wondering if two gyro sensors one in the head engine and one in the tail engine facing opposite (since your train is so short) have a code that is determined by travel direction as to which sensor it uses for data collection. 

Keep the EV3 in the center car and have it run a servo for each car?

Conceptually that's possible. It's not something that I've tried yet as I only have one Gyro sensor at present and they are currently showing as out of stock on the UK LEGO store website. However there is still the issue of determining the direction of travel, which I will address below.

44 minutes ago, Phil B said:

Can't you use a single gyro-sensor to measure direction of acceleration/movement, and thus determine which color sensor to use? If you use the Rate measuring feature to detect a change in speed/direction, wouldn't that help? You need to somehow know that you are moving backwards though, and not just slowing down.

The problem with the Gyro sensor is that it only measures angles or the rate at which an angle is changing, but it can only do that in one plane. This is fine for measuring the rate of turn for a train car by orientating it so that it measures in the horizontal plane, but the normal motion of the train, whether forwards or backwards, would not provide any turning motion for it to measure. 

46 minutes ago, Phil B said:

Alternatively, you could have special calibration tiles on your track, and the sequence in which you encounter them tells your train which direction it is moving in. 

This is the approach I'm currently taking. The train sets it's tilt threshold and calculates the tilt angle by timing how long it takes to travel between two fixed points using colour tiles (e.g. blue) in the track at a fixed interval. By "bracketing" these calibration tiles with another colour (e.g. yellow) the EV3 brick should be able to work out which colour sensor to follow. So, because the EV3 brick has no way to know whether or not the train is in motion, which way it's heading or whether it's been stopped and reversed, the current concept is to have both sensors looking simultaneously for a yellow tile and whichever sensor is leading will see it first. This sensor will then see the blue tiles needed for timing and then start to look for the tilt command tiles (probably red and green). All the time it's doing this, the linear nature of the code means that any inputs from the colour sensor at the rear of the train will be ignored.

Where I am probably making things more difficult for myself is that I don't necessarily want to have calibration tiles on the run-up to every single bend, so it has to be able to know when to continue the tilt program with the existing time interval but also recognise when it's been stopped and reversed. I also want it to be flexible enough to cope with all foreseeable circumstances, such as being able not just to tilt and centre but to tilt first one way and then the other (S bends, points, etc) possibly multiple times before centring. All of this will have to be tied-up in the code and is likely to keep me busy for a while yet. Testing this will also require more than a single car, so I'll be back to waiting for the postman to bring me the goodies I shall need.

But that's for the coming weeks. At the moment the task is to test the use of non-linear code in order that the EV3 brick can deal with the "sensor functions" while still attending to the "motor functions" necessary for a multi-car train.

[Paperinik77pk]

Thanks @Hod Carrier for the quick and detailed answer - it seems a really hard job to make it work, nonetheless you made a great experiment.

Three cars is a perfect number!

I'll follow your challenge  with extreme interest!!!

Ciao,

Davide

[Hod Carrier]

Grazie mille, Davide. 

[Roadmonkeytj]

5 hours ago, Hod Carrier said:

problem with the Gyro sensor is that it only measures angles or the rate at which an angle is changing, but it can only do that in one plane

So could a third gyro be oriented to pick up forward or reverse? Concept of course since you only have one.  For now you could program it to turn on a light (which could later be used for headlights) on the end of the engine it detects movement to.  The other sensors could be tested individually by limiting direction of travel to their fwd or rev orientation.  Then all you would have to do is integrate the three in one program ... Theoretically of course lol

Edit : 

in my head I picture a fwd gyro for tilt then servo on first car 

second car would have the movement gyro for direction the EV3 and a tilt servo

third car would have a reversed gyro for tilt in opposite travel and a tilt servo.

three sensors three motors (with ability to add a fourth car) and you wouldn't be scattering color tiles all over your layout ...

[Thai bricks]

You have chosen a very interesting and challenging project. Several train companies in Germany have done this with real trains and they all had major problems. It brings back memories riding the 612 between Frankfurt Airport and my home town. It gave me a strange feeling watching through the windscreen the train approach a corner at 160 km/h.

Have fun!

[Hod Carrier]

14 hours ago, Roadmonkeytj said:

So could a third gyro be oriented to pick up forward or reverse? Concept of course since you only have one.  For now you could program it to turn on a light (which could later be used for headlights) on the end of the engine it detects movement to.  The other sensors could be tested individually by limiting direction of travel to their fwd or rev orientation.  Then all you would have to do is integrate the three in one program ... Theoretically of course lol

I do love a good theory.

The problem is that the gyro sensors just don't work that way because they are designed solely to detect rotary motion, not linear motion. All it can do is tell the EV3 brick  either the rate at which it is moving in degrees per second or the number of degrees it has travelled, and from this input the EV3 brick can discern if it's moving clockwise (positive) or counter-clockwise (negative) through whichever plane it is orientated.

This mode of operation was the root of the problems I had with the original concept. Going forwards through a right-hand curve gives a positive input because it's moving clockwise, but going backwards through the same right-hand curve meant that it was moving counter-clockwise which gave a negative input. In this way the EV3 brick was unable to work out if it was going forwards through a left-hand curve, in which case it should tilt left, or backwards through a right-hand curve, in which case it should tilt right, because the input from the Gyro sensor is the same in each case.

I appreciate the thoughts, though. I don't much like the idea of having to use coloured tiles either, partly because it's going to be a faff to set up but also because it isn't true active tilt, so I will keep trying with the Gyros and see if I can make them work as I would like. It may be that I will need some form of hybrid version with one Gyro sensor per car for tilt and a single Colour sensor somewhere to detect direction. In this sense it would at least be active(ish) tilt but there would still need to be coloured tiles near all potential stopping or reversing points on any layout to prevent the train tilting the wrong way.

12 hours ago, Thai bricks said:

You have chosen a very interesting and challenging project. Several train companies in Germany have done this with real trains and they all had major problems. It brings back memories riding the 612 between Frankfurt Airport and my home town. It gave me a strange feeling watching through the windscreen the train approach a corner at 160 km/h.

Have fun!

Thanks for the encouragement. 

The UK has also had several attempts at tilting trains, including the Advanced Passenger Train (APT) in the early 1980s. This had a reputation for making passengers unwell, but opinion is divided if this was really caused by the train. There was a well-publicised press run from Glasgow to London in which quite a few journalists reported feeling sick, which they blamed on the tilting motion of the train. However, the truth of the matter is that they'd all been accommodated up in Glasgow at British Rail's expense and they'd all had a jolly good night out the night before, so on the morning of the press run there would have been quite a few delicate constitutions onboard, no doubt not helped by the lavish cooked breakfast that they were given on the journey.

[Phil B]

Two more options that I can think of to detect the direction of motion:

1. Dangle a technic beam vertically under the train, with a touch sensor inside the train on either side. As the beam hits the track sleepers, it will push the top part of the beam against one of the sensors. By reading out which sensor is touched, you know the direction the train is moving.

2. Mount a large 40 tooth gear horizontally (on a vertical axle connected to the driving wheels or any other train wheel) inside one of the carriages, with a color sensor aimed at it. Put a sequence of 3 colored tiles on the gear (or multiple sequences), for example black-yellow-red. As the train moves, the gear will turn and the sensor will detect the sequence of tiles passing under it. If yellow follows red, the train is moving one way, if red follows yellow it is moving the other direction.

 

Edited November 16, 2019 by Phil B

[Roadmonkeytj]

So as I have never used one I've done some digging THIS video was pretty eye opening.  The author may be young but he does his research and makes some well informed video of ways to make Lego robotics.

The interesting thing I took away from this coupled with the info you shared is that that the gyro measures angular velocity which makes sense that it can not know which direction to tilt without further input.  

So I do believe you can go back to using a single gyro for tilt if you use a separate sensor for speed/direction

1 hour ago, Phil B said:

Mount a large 40 tooth gear horizontally (on a vertical axle connected to the driving wheels or any other train wheel) inside one of the carriages, with a color sensor aimed at it. Put a sequence of 3 colored tiles on the gear (or multiple sequences), for example black-yellow-red. As the train moves, the gear will turn and the sensor will detect the sequence of tiles passing under it. If yellow follows red, the train is moving one way, if red follows yellow it is moving the other direction.

I believe this would be a good option as you could get reliable direction and speed input.  I recall reading somewhere on here (forgive me for not being able to search for the op).  They were adding DCC sound card to their loco and needed a speed sensor.  The solution was painting a 2x2 round white brick in quartered sections with black.  (I know others have glued a magnet) then powered it off the wheelsets with the sensor above.

With this you could easily tell the EV3 if it should use the input of positive or negative ”tilt” then based on direction input from the rotation ”accelerometer” tell it which way to tilt.

 

[Thai bricks]

Since I know almost nothing about Mindstorm this may be a silly question to you: Can you not use MS also to control direction and speed? This should simplify programming, as the controller 'knows' about both.

[SteamSewnEmpire]

Threads like this make me glad that I deal exclusively in steam trains. Woof. What a project.

[Phoxtane]

10 hours ago, Phil B said:

Mount a large 40 tooth gear horizontally (on a vertical axle connected to the driving wheels or any other train wheel) inside one of the carriages, with a color sensor aimed at it. Put a sequence of 3 colored tiles on the gear (or multiple sequences), for example black-yellow-red. As the train moves, the gear will turn and the sensor will detect the sequence of tiles passing under it. If yellow follows red, the train is moving one way, if red follows yellow it is moving the other direction.

 

8 hours ago, Roadmonkeytj said:

ding somewhere on here (forgive me for not being able to search for the op).  They were adding DCC sound card to their loco and needed a speed sensor.  The solution was painting a 2x2 round white brick in quartered sections with black.  (I know others have glued a magnet) then powered it off the wheelsets with the sensor above.

With this you could easily tell the EV3 if it should use the input of positive or negative ”tilt” then based on direction input from the rotation ”accelerometer” tell it which way to tilt.

I'd suggest looking at picking up a handful of part number 2958pb002 off Bricklink.

I have a couple of these and I think they were explicitly designed for use in old Technic stuff for sensing rotary motion.

 

1 hour ago, Thai bricks said:

Since I know almost nothing about Mindstorm this may be a silly question to you: Can you not use MS also to control direction and speed? This should simplify programming, as the controller 'knows' about both.

This seems like the easier answer - why not use a Mindstorms motor to drive the train itself? It's got enough power that you could gear it up a bit to better match the speed of a standard train motor.

[Phil B]

18 hours ago, Roadmonkeytj said:

I believe this would be a good option as you could get reliable direction and speed input.  I recall reading somewhere on here (forgive me for not being able to search for the op).  They were adding DCC sound card to their loco and needed a speed sensor.  The solution was painting a 2x2 round white brick in quartered sections with black.  (I know others have glued a magnet) then powered it off the wheelsets with the sensor above.

 

9 hours ago, Phoxtane said:

 

I'd suggest looking at picking up a handful of part number 2958pb002 off Bricklink.

I have a couple of these and I think they were explicitly designed for use in old Technic stuff for sensing rotary motion.

 

Two-toned color wheels can tell you IF there is movement, but not in which direction the movement goes. For that you need a three-toned color wheel, as I described above.

[Phoxtane]

1 hour ago, Phil B said:

 

Two-toned color wheels can tell you IF there is movement, but not in which direction the movement goes. For that you need a three-toned color wheel, as I described above.

Hence why you would need two of them, and two sensors (maybe RCX sensors with the proper adapters), offsetting one from the other such that in direction of travel one is always triggered before the other, and vice versa.

[Roadmonkeytj]

3 hours ago, Phil B said:

 

Two-toned color wheels can tell you IF there is movement, but not in which direction the movement goes. For that you need a three-toned color wheel, as I described above.

Very true ... The DCC card uses the voltage input to determine direction ... But something similar with colors was what I had in mind.  Should have been more clear.

[Paperinik77pk]

Ciao @Hod Carrier !!!  Yesterday I saw a video on the British APT train, and  saw a demo of the AV3 accelerometer. I was wondering how to better make the EV3 understand acceleration and lateral movement.

I try to explain - as far as I understood all the tilting trains have two main goals - the first one is to approach curves faster (banked or not) , the second one is to reduce lateral acceleration for passengers

I was thinking about this thing - use the accelerometer as a passenger - so not strictly bound to the chassis, but mounted on an hinged support. So if the train is going forward,the accelerometer it is pushed backwards and vice-versa.

I think it could work also with side acceleration - in this case a two-way hinge is needed.

 The readings should tell the EV3 the direction and if the train is going straight or not (the inputs are reversed, so if the accelerometer reads back it means the train is going forward, and if it reads left it means the train is approaching a right curve (and then needs to tilt right)

It is pure theory - since I do not have the EV3 to make tests - sorry - I'd like to know your thoughts about this approach

 

[zephyr1934]

On 11/15/2019 at 11:15 AM, Hod Carrier said:

The problem at the moment is working out how to make the EV3 brick do more than one action at a time, but I think I have a solution.

I'm not sure this is helpful, but what I did long ago with the RCX brick was to do an infinite loop. At the start of the loop I checked the instantaneous status of all of the sensors, and clocks and whatnot that I wanted to check. These checks were done serially, one after the other. For each one the only branch I took would be to set a variable and then quickly return to the main loop and move to the next. This way, I sampled all of the sensors before taking any action that would keep me from hearing any of the sensors, and no branching to respond to a given sensor that might cause me to skip another sensor. Then the last half of the loop, I would progress serially through each of the variables, if true I would take the branch to respond and reset the variable or if false just skip this action, then return to the loop to check the next variable. Like checking the sensors, the responses were serial and after each one I returned to the main loop. I was also able to implement timed actions, in this case, the last step in the loop would start the timed action, and the first "action" in the loop after checking the sensors was to see if the timer had run out and I needed to stop the timed action.

In my case I was controlling two semaphores with one RCX brick. Each semaphore took a little time to go up/down. So I checked to see if a train was present on track 1, then on track 2. Then, for track 1 if the signal was up and the variable indicated a train was present the RCX would start moving signal down, set a variable to indicate the status of the semaphore and start a timer for the motion but then return to the loop without waiting for the timer to end, ditto for track 2. Next, check to see if the move timer had run out for track 1, if so stop moving that semaphore, ditto for track 2 (I used bands to serve as clutches so I expected to be just a little late). My assumption was that it would be a couple of cycles before the "stop moving" was implemented, but I never tracked it. Next, if track 1 is occupied reset the "timeout" timer, ditto for track 2. If the timeout timer for track 1 made it all the way to the end then start moving semaphore up and start the move timer but return to the loop without waiting for the move to end, ditto for track 2.

On 11/16/2019 at 8:48 AM, Hod Carrier said:

This mode of operation was the root of the problems I had with the original concept. Going forwards through a right-hand curve gives a positive input because it's moving clockwise, but going backwards through the same right-hand curve meant that it was moving counter-clockwise which gave a negative input. In this way the EV3 brick was unable to work out if it was going forwards through a left-hand curve, in which case it should tilt left, or backwards through a right-hand curve, in which case it should tilt right, because the input from the Gyro sensor is the same in each case.

A few thoughts, first, how are you going to propel the train? If it is by the EV3, then problem solved, it should know which way it is going without any further sensing. Second thought, to let you keep progressing on this project while you scratch your head to determine the direction of travel, either make it be a one way vehicle (that just looks like it is bidirectional) or have a selection at startup where you press a "button" to choose the direction of travel. I don't think it is unreasonable to require human input for that binary decision. The button could be virtual or you could build a touch sensor in to make the selection mechanically. Third thought, there was an IR sensor for the NXT, if that ever made it to the EV3 and you are using an IR receiver to control the train's motion, perhaps you could also have the EV3 "listen in" to the same IR commands. Though the IR receiver was really low power, so you had to be within half a meter or something like that before it would sense the IR controller.

[Toastie]

@Hod Carrier

Sorry to hear that your project did not make into the competition.

However, this is a really nice and challenging project and thus per definition in “my world”

As @zephyr1934 has already shown avenues to go, I’d only like to chip in a couple of additional thoughts.

This project certainly has (at least) five major challenges to think about:

• Hardware for propulsion and tilting (motors, gearing)
• Hardware for sensing (speed and angle)
• Software to control the hardware.
• Software to establish communication between you and the remote system.
• In addition, how much of intrinsic automation do you want to equip your train with? E.g. You supply the instruction “Go forward at speed 7”: Should the engine/train accelerate using a profile, with controlling the speed rather than the actual setting on the motor (PID or the like)?

Now, I’d put the hardware on for later, as the software needs to be designed first. Learned that the hard way; when you do it the other way around, mechanical restrictions may blow away all your software dreams and you’d need to redesign from scratch. The one thing I’d make fix is: Type of PBrick, sensors, and actuators “required”.

As far as I can tell, you are going with an EV3 PBrick along with EV3 motors, is that correct/fixed? As these motors have built-in rotation sensors, PID is already solved. I’d go with that for propulsion.

The tilting mechanism is also with EV3 motors, right? So that is also taken care of as you can go to a certain angle.

Instead of the tilting sensor, I’d measure the rotation angle of one of the bogies. With that information and the speed you already know, you could calculate a corresponding tilting angle, let that max out or reset to zero within constraints you are defining.

With regard to programming: SCOUT, RCX(n), NXT, and EV3 can do multi-tasking (sliced time). I’d thus set-up one task (as infinite loop) recording all relevant sensor data, maybe a little data manipulation, and make these globally available. Another task (another infinite loop) could do communication and again provide relevant data to the main task (light on/off, speed setting, etc.). Next a task to handle the tilting mechanism (infinite loop). The remaining main task starting all this in a sound a logical way and then goes into an infinite loop manages the motor power setting for propulsion and coordinates all the other stuff. Advantage is that you can individually set up each looping time. Some tasks may need to respond swiftly (messaging) others are not required to run with micro second temporal resolution …

Have done “comparable” (no tilting though!!!) things with an historic RCX PBrick and plain train motors (no built-in PID) as well as with NXT PBricks for my train layout (train, switch point, bridge, light control).

(Let me know if you need more on this)

And then I’d try to figure out how to build all this. Maybe linear actuators could help or whatever. Just go to the Technic forum and ask - they do breathtakingly >crazy< things over there. To say the least. And to the Mindstorms forum to get the latest software hacks - I believe, they can already do time travelling using an EV3. At least it sounds to me like that.

All the best and good luck with this very, very interesting project!

Thorsten

[Hod Carrier]

My apologies for not replying sooner. Things have been a bit hectic and, although I've been able to read the excellent contributions, I've had not had the chance to reply. However, I am very touched by the amount of suggestions and encouragement I have received. Everyone's willingness to share is why I love this community so much, so thank you to everyone. 

I'm a little at a loss to know where to start, but I shall try to cover as many of the points raised as I can.

Firstly I just wanted to say that my intention with this project was to keep things as simple as possible while acknowledging that there would be complex issues that had to be addressed. Some of these issues could be addressed through the hardware while others would need a software based solution. The trick has been to identify which parts of the project would require which solution. However, this was always going to be a learning process for me because I only have limited experience with Mindstorms and am still not very competent with Technic.

The concept of this train is to remotely control the train's direction and speed in the conventional way and to have the EV3 brick deal with the tilt automatically. Consequently there would be no direct communication between the train and the operator with regards to the tilt except to start and stop the program. In order to give the train the necessary speed and to simplify construction, PF train motors controlled by an SBrick were chosen. Any other form of propulsion would be far more complex and require the drivetrain to account not just for bogie rotation but also for tilt and would consequently take up a lot of space inside the train. Tilt servos would be EV3 motors controlled by the EV3 brick, as I knew that these are very precise and controllable. In this regard, the selection of hardware was relatively straightforward and I was able to design the mechanical aspects around these components.

The downside of this approach is that the propulsion and the tilt are two completely separate systems, which is why it's necessary for the EV3 brick to know which way it's going and how fast it's cornering. I will admit that I was aware of this problem (among many others) at the concept stage and gave it a lot of thought. I guess that the simplest solution to this is to set a direction variable within the tilt code and alter this each time the train is reversed, either through a button press, a sensor input or simply sent in the code from my laptop via Bluetooth, but this gets away from the fully automatic program that I set myself as a goal. (As an aside, I did work out how to reverse the inputs of the Gyro sensor. Simply flip it over upside down and the inputs are reversed. This could be incorporated into the train using a PF servo motor per sensor controlled from a reversing switch in the SBrick control profile to remotely flip all the sensors in one go. On the downside this would be expensive and bring the total number of motors inside a three car train up to an eye-watering eight!!)

I believe that the closest I shall get to this is by using appropriately laid-out colour tiles in the track sensed by colour sensors and interpreted by the EV3 brick using the appropriate code, as I outlined before. But I shall need to build a prototype to test this and make sure that the code works correctly. Of the suggestions made so far, an internal colour wheel synchronised with the propulsion is probably the best, as this basically internalises the same process within the train and is the most likely to work reliably. I have also found the colour sensor to be the most reliable performer and the easiest to write code for, as it can be used to tell the EV3 brick the speed and direction of travel as well as instruct it when to tilt.

Combining the propulsion and tilt under the EV3 brick is an interesting idea, but I'm not sure how best to implement this. Mindstorms medium motors are precise but slow and would require a lot of gearing up to get performance anywhere near that of the PF train motors, as I discovered with the EV3 powered D800 Warship class diesel I presented earlier this year. The large motors may be better in this regard, but they are not very train-friendly in terms of their size and shape. In either case, these motors would still need a drivetrain that could take account of bogie rotation and tilt and, with three tilt servos only leaving me one spare motor port, it would have to be powerful enough to get by with just a single motor. The only other option would be to have a servo motor controlling the power dial on the PF battery box instead of remote control via the SBrick. Whichever of these options I chose I would still need to write the appropriate code and provide means for remote control (the EV3 IR receiver is also not very train-friendly).

I'm unsure of the EV3 brick's abilities to "eavesdrop" on the control instructions and act accordingly. I'm not using IR, but the EV3 brick has Bluetooth and the code allows for it to make connections with other devices and send and receive messages, although whether this means that it can passively receive and interpret Bluetooth messages sent between two other devices (in this case, my mobile phone and the SBrick) is something I do not know. The help files suggest that this feature is mostly to permit EV3 bricks to communicate with each other and to feed into the programs each is running. I think I shall need to research this, as this is probably the most promising avenue because it will unify the propulsion and tilt systems.

My abilities to code are progressing, and I am already making use of infinite loops in my programming. But I have learned that if you write linear code then the EV3 brick behaves in a very linear manner, such that it will have to complete the first task before moving on to the second. Where this causes me a problem, and why I need to learn how to make the EV3 brick do two things at once, is because the motor functions of the tilt system will involve a time delay in order that each car is tilted at the correct time and in the correct sequence. If I write that as a linear instruction it won't be able to see any more colour tiles until the instructions for the motor functions are complete. This isn't ideal for me because I want the train to be looking for the next set of instructions at all times whether there are motor functions going on or not and to act on them accordingly.

What's really been holding me back is learning how each sensor works, what inputs I can expect to get and how to use them. The biggest disappointment was the HiTechnic Accelerometer which really didn't work as I had hoped. Perhaps this was partly due to my expectations or maybe the way they were described, but for the use I had hoped to put them to they were sadly lacking. The LEGO Gyro sensor has also been frustrating. I'm still trying to get to the bottom of how to get the best out of it, but it's performance is very hit and miss. With the test car doing laps and running a gyro-based tilt program it would sometimes tilt correctly and sometimes not. I've tried tweaking the code to get it to perform better but I'm not having a lot of luck. I sense that perhaps I'm pushing it too far outside of it's parameters due to the speed at which I'm expecting it to operate. However, my good old friend the LEGO Colour sensor has been the most reliable performer. It rarely misses a tile even at high speeds and the code I have written for it so far gives very nice performance. But it just isn't active tilt. *Sigh*

Just to pick up on the point of where to mount the Gyro sensor. I've decided that the best place for it is on the car body rather than on one or other bogie. The reason for this is that it will react equally no matter which way the train runs, whereas mounting it on a bogie might lead to uneven responses depending on whether that bogie is leading or trailing into a corner.

I'm already lurking on the Technic and Mindstorms boards. Those guys speak another language, but they come up with some seriously impressive stuff.