Hod Carrier

Misadventures in Tilt

Recommended Posts

If you are concerned about the performance of the EV3 motors ... note that you can control a PF train motor from an EV3 brick in at least 2 ways:

1. By making a custom ev3 -> PF cable. Instructions can be found in my answer to this StackExchange question: https://bricks.stackexchange.com/questions/2325/how-to-use-power-functions-with-mindstorms-ev3/4743

2. By using a MindSensors PFMate. This custom component, together with its EV3 code block, allows you to control up to 4 PF IR receivers from 1 port on the EV3, so you can use up to 8 PF motors on one EV3 port.

Once you have speed and direction control implemented like this, all you need to do is sense a curve (for example by using a gyro sensor in each car) and then control each associated servo to make the car tilt the right amount in the right direction. You can just write several independent code sequences (each starting with their own Start tile) within your program and all these programs should work concurrently. So one program for each car to read the gyro and adjust the tilt, and one central loop to control the PF train motor.

Share this post

Link to post
Share on other sites

That are a lot of thoughts and efforts you already put into it! So there needs to be a solution as well - this has to work in some way or the other.

Another questions: What programming language are you using for the EV3?

The linear programming will not work for this project, I believe. In the good ol' RCX world using NQC "start  task_name" would - well - start task task_name. When that one is an infinite loop, it runs "in parallel" to the main loop, which was starting the task. In NXT-G (the graphical programming language of TLG for the NXT brick), you just pull another branch from the main branch (symbolized as Technic beams) and you have created a new task. I believe for the EV3 it is similar, but don't know for sure.

Or are you using any 3rd party software?

As others have mentioned already: I for sure would use the EV3 to control everything. In this thread @Cosmik42 has implemented EV3 support via Bluetooth LE communication for the PoweredUp (Control+) stuff. On page 14 in his version 1.0 the EV3 is integrated.

Which means that it is doable. The EV3 -> train motor converter cable is one option to go.

All the best

Share this post

Link to post
Share on other sites

Oh dear, this is starting to get a lot more complicated than I imagined. :sceptic:

I appreciate the suggestion to use the EV3 to control the propulsion and can see the benefits to doing so, but I'm not sure that it's necessarily the best option to suit the parameters of this project. What I'd like is to be able to "drive" the train in the conventional manner using either a remote or an app which will require some means of communication between the operator and the EV3 brick, even with a converter cable or the PF Mate. The obvious solution to this is to use the EV3 IR beacon and receiver but, as I mentioned already, it's not very train-friendly.

As I mentioned above, the ideal set-up would be for the EV3 brick to "eavesdrop" on the commands sent via Bluetooth from the SBrick app and to interpret these for the purposes of the tilt program. This keeps the control hierarchy in the shape I would like it to be and allow simple user operation. However, this is going to be a rather large task. Some reading reveals that simply to get the EV3 brick to use Bluetooth 4 BLE to enable this level of communication would require an external dongle and the use of ev3dev, which does not support LEGO's EV3 programming language. While I know that this spec allows the EV3 brick to control the SBrick I don't yet know if this means that it can receive and interpret commands from the SBrick app. It would also mean learning how to code using Python or similar; something that I have never previously done. While @Cosmik42's excellent software does allow cross-platform communication, it's not clear to me how it could be implemented into my project. The main thrust seems to be automation and it appears also to require knowledge of at least some sort of programming language.

As a consequence, this is something that will have to go onto the back burner as a long-term project and for the time being I will concentrate on the colour tile controlled proportional tilt to give a facsimile of active tilt operation.

Share this post

Link to post
Share on other sites

So building on what was already mentioned ... A geared bogie powering colored 2L pin connectors 

If it sees rby it knows it's going forward

If it sees ryb it knows it's going reverse

The amount that it cycles could interpret speed and correlate to degrees of tilt needed.



Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.