Auto rotate from Raspberry Pi/RetroPie ...

[Bolthouse]

Hi All,

I understand all the mechanical and electrical aspects (wiring and switches) of a rotating monitor ... but I'm at a loss for how I'm going to get my Raspberry Pi, running RetroPie, to trigger the rotation. I see a lot of chatter about MRotate, but that seems to only work on Windows machines.

If you offer any advise, understand that I have virtually zero programming knowledge and I don't understand micro-electronics well. So explain like you're talking to a 8th grade science student. I can usually fumble my way through with a little trial and error, but I'm operating at a very basic level in these areas.

It seems like I need a motor control board for controlling the motor ... which can connect via the GPIO pins or via a USB port. But I have no idea how the software will interface with the hardware, so I'm unsure of what I'm looking for in a motor controller? The Pololu simple motor controller seems popular and appropriate, but I just have no experience to know if it's the right choice.

Obviously, I also need a motor, but I have no clue what type, style or strength of motor I'll need. It seems like a basic brushed DC motor will work for me, but I'll probably buy a bunch and test them out. That said, it would be nice to have a little direction. Mechanically, my monitor will be mounted to a swivel plate, and I will mount a laser cut acrylic gear to the back of the monitor ... so my motor will drive the monitor via that gear. It's a 19" LCD monitor, so not too big or heavy and the swivel plate will hold all the weight ... so the motor should only have to apply a bit of rotational force.

I have search the forum for this info, but it's only gotten me so far as to ask these questions.

This is all I know to ask at this point.

Your feedback is appreciated.

Thanks!

[DaOld Man]

Hello Bolthouse, and welcome to the forum!
You are correct that MRotate only works with Windows.
I have tossed around the idea of a version for RPi, but havent had a lot of time to explore it.
Just right off the bat, it would probably be easier to do through the GPIO.
And we would need a way for the program to know which orientation the game being played needs.
Darthpaul just put together a console that turns on LEDs based on emulator selected, maybe he can contribute his process.
I will start thinking about that, because I may want to do the rotate screen with Pi myself.
If any programmers on here have some ideas, lets hear them.

About the mechanical part, Im interested to see your gear setup.
I used a 12 VDC motor that was made to raise the headlights on a Firebird car, very similar to a wind shield wiper motor.
These motors are very powerful and should easily turn an LCD monitor.
Looking forward to seeing how your project goes.

[darthpaul]

I have been thinking about this as well but I don't think from a software point of view it's going to be easy. Retropie and Emulationstation are not built at the moment to easily do something like this but anything is possible. Since you are going to be using a LCD monitor it should be pretty straight forward rotating it.

[Bolthouse]

Thanks for the warm welcome! I'm really looking forward to this project.

The GPIO pins do seem to be the more direct electronic route for most things (as I understand it, anything USB would require drivers), but it should be noted that I will have a ControlBlock (http://petrockblog.storenvy.com/products/13969497-controlblock) connected to the GPIO pins. While the ControlBlock leaves a number of pins open, it makes them a little less accessible as it covers the RPi. Also, I'm not really sure which pins do what (though I know there's a simple schematic for that), so I don't know if any of the available pins would be useful to trigger rotation.

I'll definitely share my plans and progress as soon as I have something to show. For the last month I've just been identifying, ordering and waiting for parts to arrive. I actually live in Hong Kong, which has been pretty nice for sourcing parts ... either through Ebay or the ample electronics markets in HK and Shenzhen. Oddly, the larger obstacle has been sourcing materials like wood and screws, as Asia inst really a DIY sort of culture. Fortunately, a fantastic maker space recently opened in HK; which gives me access to a wood/metal shop, laser cutter, CNC mill and 3D printers. It's rather entertaining, but the one thing I absolutely can't find in Asia, is T-molding! But I'll be back in the US in July and August, so I'll just pick some up while I'm there.

I'm just now getting into the nitty-gritty of the design and building the cabinet out in SketchUp, so I'll post that when I get it done. That will give a much better picture of the mechanics.

I also plan to publish a detailed blog, covering every aspect form parts selection, through the actual build.

Anyway, let me know if i can help in any way with getting a version of MRotate working on the RPi. Again, I'm not a programmer, so I'll probably be as useful as a sack of rocks ... but I'll do what I can.

[darthpaul]

From what I have been reading, it looks like you could be the first one to do automatic monitor rotation using a Raspberry Pi. I found out you are going to have to create a small text file for every vertical game rom and place that file right below the game rom and call it, rom name.zip.cfg.
This is what should be in the text file:
video_allow_rotate = true
video_rotation = 3
I'm also thinking that maybe here is where a python script should be called that would trigger the monitor rotation. The problem then would be getting the monitor back to horizontal. I guess you could create another text file for all the vertical games and call a script that would rotate the monitor back to horizontal, or on exit of every game, the monitor would return to the horizontal position, that would only involve one call to the script placed in the runcommand file.

[DaOld Man]

Very interesting.
Startcom is used with Mala to send orientation to mrotate.
Mala uses the mame.xml file to get game orientation. (if memory serves correctly.)
startcom gives an option to select orientation based on emulator.
Im thinking, use the mame.xml file to create a txt file that python (for the RPi) can use to get monitor orientation by game.

Remember, mame.xml is the memory, Mala is the memory sorter, startcom is the brain that processes the info passed by Mala, and mrotate is the muscle.

If we can convert mame.xml to a format that python can use, minus all the unnecessary stuff, we might can make this work.

Now if we can only figure out a way to safely shutdown the RPi by pulling the cord, we will make PBJ happy. LOL

[darthpaul]

Is there an xml file?

[DaOld Man]

Is there an xml file?

http://www.logiqx.com/DatFAQs/MAMEDat.php

[darthpaul]

But does Retropie use it?

[DaOld Man]

I don't think so, but could be wrong.
Im thinking of a script that will read the xml file, and assign 0 for horz or 90 for vert for each game, since we don't need all the other stuff in the xml file, then write this info to a txt file that python can read. (This to be done only one time, unless new games are added).
Then have a script that reads the txt file and passes 0 or 90 to the python mrotate, based on game selected.
This last script could be called from the command line(? im at work and cant remember what day it is), the option in retropie (or is it emulation station?), that allows you to run a script before starting the game.

The only problem I see right now is can emulationstation pass the name of the rom to this script?

Im sure there is an easier way to do this, perhaps someone more experienced with ES and python can help?

Or, it could be a learning experience for someone. (hint hint)

[darthpaul]

You can get the rom name the same way I'm getting the system name to light my LEDS. 
/opt/retropie/supplementary/runcommand/runcommand.sh  The rom name parameter is $4.
Romlister can create a list of all vertical games so I don't see why we would need an xml file.

[DaOld Man]

Cool.
What kind of file does romlister save the vertical game names to?

[darthpaul]

text

[DaOld Man]

Bolthouse:
You still interested in this?
I have made some leadway on this project.
I have mrotate for RPi written, it utilizes the GPIO to control the motor drive.
It is a bit complicated right now, but I am working on making it more simple.
Right now, using attract mode (which also has Emulation Station built in), I am able to call mrotate when a game is selected.
You have to build a list of the games that run in vertical mode.
Mrotate turns on the output to turn monitor to vertical, if the game is in the list.
It also copies over a vertical setup of mame.cfg so the game displays in vertical.
If not in the list, Mrotate turns on output to turn monitor horizontal.
A horizontal setup is copied over mame.cfg also.
The output stays on until an end-of-travel limit switch is made, or a preset time has expired.
Since I cant seem to turn emulation station menu vertical, mrotate will turn the monitor back to horizontal when the game exits.
Because I am still playing around with this I will not do a complete write up until I am sure it is finished.
But if you would like to try it on for size, I can walk you through the setup.
I am liking attract mode, and I plan to learn how to write plugins for it, perhaps I can simplify this even more for attract mode.

[DaOld Man]

Project is not yet completely finished. I need to tweak the code to allow you to select which emulators are vertical enabled, all others will be horizontal only, no matter which game is selected.

Here is a short video showing my temporary setup.  I say temporary because of the jumble of wires.
Im using a T-cobbler board to connect the Pi GPIO to a bread board. This is for testing only. In real life, the drive would connect directly to the GPIO pins.

https://www.youtube.com/watch?v=CFfYjMufCSA&feature=youtu.be

Another short video showing the actuator and the limit switches.

https://www.youtube.com/watch?v=C-E3BjsuwIg&feature=youtu.be

Im using the rig I built that utilizes a 24 volt actuator. I only have 12 volts on it right now so it rotates pretty slow.
here is a video displaying rotating automatically.

https://www.youtube.com/watch?v=9vEC1sgYe_4&feature=youtu.be

Sorry for the poor quality of the videos, I used my iphone and trying to do two things at once tends to make me shaky.

[DaOld Man]

Ok, first step, hooking up the hardware.
Mrotate uses pins 40 and 38 as the default outputs to the drive.
It uses pins 35 and 37 as the default limit switch inputs.
You can change these in the mrotate_settings.txt file if you want to use different pins. (More info on that later.)
On my test rig, I used a small drive.
For the limit switches I use switches that are normally on until the end of travel is reached, then they open.
Right now Mrotate is set up to only monitor the switches in that fashion. I may give the user the option to change this, if the demand is there.
I also highly encourage you to add 500 ohm resistors (1/8- 1/4 watt), between the inputs and the ground.
This is to protect the RPi, because the pins can be set as inputs or outputs by software, it might harm the Pi if something sets one of your limit switch connected pins as an output and turns it on while connected to ground. The resistors will put a current limit on the circuit if that ever happens. Connecting an output directly to ground is not a good thing.
Here is a fast and dirty hookup diagram. On Mrotate, I have decided to use pin numbers and not GPIO numbers, since they dont match and it's just easier for me to count out the pins to be sure Im connecting to the right ones. I can make this selectable (Pin # or GPIO #) if the demand is there.

[Bolthouse]

Hey! Looks like you've been doing some work since I've been gone!

I actually live in Hong Kong and just got back from a 10 week sales trip to the US, so this whole project has been on a shelf during that time. I also have a 2-year old and another on the way in January, so projects like this tend to get shelved for long periods of time anyway.

However, I did take advantage of my time in the US to buy up a variety of parts and tools for my cabinet. Not that you can't get arcade parts and supplies here in HK, but arcade cabinets here are more the Japanese style, which is a far cry from what grew up with in the US. This is to say, I think I've finally acquired all the components to complete the cabinet.

Further to your question of "am I still interested in this project", most definitely! I'm just not to the point of making the monitor rotate yet.

It'll be a slow process of working toward that point, but rest assured, when I get there, you'll be hearing from me.

Thanks for the work you've done on this issue thus far. It definitely won't go to waste!

[Bolthouse]

I noticed in your schematic that you have a motor controller between the RPi and the motor itself. I forgot until just now that I will need a motor controller.

While I understand how to physically wire things up, it would be great if someone could recommend a good motor/motor controller that would work well for turning a monitor with the RPi.

My best source for finding specific electronic components in Hong Kong is ... http://hken.rs-online.com/web/

I know it's a bit lazy of me to ask, but if someone more knowledgeable could go onto that site and link me to the proper parts, it would be greatly appreciated.

Alternatively, if there is someone online selling motor/controller kits for rotating arcade cabinet monitors, I would be very interested in that.

Thanks a bunch!

[Bolthouse]

Sorry for the flurry of questions. Like I mentioned, I'm just getting back into this project and trying to remember where I left off.

With regard to the motor controllers, I found a previous post of mine where someone recommend the "Pololu Simple Motor Controllers" ... https://www.pololu.com/category/94/pololu-simple-motor-controllers

Anyone have experience with these? They seem to be in line with the hardware I'm already using, but IO'm not really sure how to pair them with an appropriate motor.

With regard to motors, is there a particular voltage, RPM or torque requirement?

I realize that windshield wiper motors are often recommended on this forum, but I'd rather go with just a general purpose DC motor ... rather than re-purposing a motor that was designed for a specific task.

[DaOld Man]

Hi Bolthouse!
Welcome back and congrats on the new edition to the family!!

I thought everyone had lost interest in the Pi-rotate project, so I kinda shelved it.
I do need to work on mrotate for Pi again, a few loose ends I need to fasten down, so I will try to get the project back out and dust it off.
May be a few days though cause life is getting in my way.

About the motor controller: Yes you will need a device that can handle the large power (compared to a Pi output) that it will take to run the motor. This device is normally called a drive.
There are several drives available on the market, and if you have time, patience, and the tools you can build it yourself.
However there are so many cheap options out there it may be best just to find what you need and buy it ready made, unless like me, your first hobby was electronics and you enjoy "Building your own".
What type drive do you need? This depends entirely on what type motor you choose.
So you need to choose your motor first.

What type motor? That can be a tough question, or it can be very simple.
You need to figure out how much power you need to turn the monitor.
How heavy is your monitor? What type of bearings or pivot do you plan to use to allow it to turn? How fast do you want it to turn? (Too fast can be dangerous and too slow is frustrating.)
You need decide what type power supply you need for the motor. The power supply must closely match the requirements of the motor, and it must supply the current needed for the motor.
Seems the most common motors used for this purpose, IMHO, are DC brush types, 12 volts DC.
How big the motor is goes back to the second line of this paragraph. Bigger the motor, more work it can do.
But bigger the motor, more power required to run it, more space consumed in your cabinet, and probably more noise when running.
The speed of the motor is important too. Although you can slow a DC brush motor down by decreasing the voltage going to it, you want to make sure it can go as slow as you want it.
If the motor is still too fast (you only need the monitor to turn 90 degrees), you will have to reduce the speed by using gears or pulleys and belts.
It can get complicated mechanical wise. But you can buy DC motors with gearboxes attached that does most of that work for you.

The windshield wiper motor is common because it needs 12 VDC, which can be supplied by an old computer power supply. It has a built on gearbox, which means the output is pretty slow, and it is a strong motor.
I used one on my first rotate project that turns a 19" CRT monitor.
But it is loud when it runs.
Other motors that people have used on here are the tiny motors (forget the name), steppers, and servos.
Steppers and servos require special drives and most likely digital interface with the computer, which Mrotate for Pi will not do.
I used a actuator (screw) motor on my experimental Pi thing for this project.

So I guess you first need to concentrate on how you are actually going to mechanically turn the monitor.
Build the frame for that, see how much force you think will take to move it, then decide on the motor and how you will couple the motor to the monitor, then pick out the motor, the power supply, and the drive. In that order. (I would keep the power supply for the motor separate from the power supply for the Pi.)

I know this seems a lot to chew, but it's not really that bad, I do tend to ramble a lot in my old age LOL.
Just first concentrate on how you are going to perform the act of physically turning the monitor.

We are here to help, several people have done this and I havent heard anyone say they regret it.

[Bolthouse]

Thanks for all the feedback! I've actually been trying to work out all the various classes of motors/controllers, as well as all the relevant specs (voltage, amperage, torque, RPM, etc.) in the past few days.

I seem to have come full circle back to the windshield wiper motors you're so fond of. The one online electronics dealer that I know who delivers quickly to Hong Kong has a variety of motors, but it seems like their high torque motors (gearbox or not) are priced around $200 - $300 USD. So I see why the windshield wiper motor is such a good option for hobbyists. Fortunately, Ebay has a variety of wiper motors that ship from Korea or Japan for about $60 plus shipping.

As for the motor drive/controller, I'll probably go with one of the Pololu simple motor controllers that where recommended elsewhere on this site. They seem to handle a 5.5v to 40v range up to 12 amps or so. That should cover just about any wiper motor I can attach to it. Plus they're well documented/supported, which means I'm not totally in the dark when it comes to setting them up.

The screen I have is a 19" Fujitsu panel that I pulled out of an old 5:4 Sony monitor (I'll crop it to 4:3 with a bezel) ... https://www.cnet.com/products/sony-sdm-hs95-s-lcd-monitor-19/specs/  ... which I proudly upgraded with a new LCD control board (adds HDMI, so no DVI adapter needed) and converted it from CCFL back lights to LED (significantly reducing the power consumption). It's also a really good LCD screen with even viewing angles from all sides, perfect for rotating.

The monitor will be mounted with a swivel plate, then rotated using gears or a screw drive ... or maybe something else. I've got a good handle on the mechanical aspects of rotation, I'm just fuzzy on motors and motor controllers ... but that picture is starting to get more clear as I research.

I won't even have the motor and controller in my hand for a few more weeks, so don't rush on the software side.

Thanks for your help!

[DaOld Man]

Hi Bolthouse.
Sorry I had to back away from this hobby for awhile.
About the windshield wiper motor: Do you have any junk yards or used parts stores? You should be able to pick one up for around 10 us dollars.
I can get you one here, but Im not sure what shipping would cost. That may be the catch.

[DaOld Man]

Here is a video of my test rig using a 24 VDC actuator to rotate a monitor. The actuator is controlled by the RPi, with Emulation Station.

[raph]

A lot of people use RaspPi's to control servos using the same Micro Maestro controller board that I used to do my PC-based project.

Some links:

http://www.linuxcircle.com/2015/02/08/raspberry-pi-pololu-maestro-python3-tornado-servo-control-part-1/
https://www.pololu.com/blog/68/controlling-a-maestro-in-c-using-a-raspberry-pi
https://github.com/FRC4564/Maestro

[ZoOl007]

Hi, I am not really a hardware guy but I actually coded/anticipated for rotating monitor support in RGBcommander.
It has all the (mame) monitor orientation data build in and it runs on pi2/3, linux and windows. It actually uses that data already. It would 'just' be a matter of adding support for the hardware.
So, if people are willing to list me the most used/popular usb motor steering boards I can look into this.
The end result would be that end users can activate a certain board in the daemon's configuration xml and then the monitor would rotate on a rom or emu based setting.

[mahuti]

Rather than direct support for usb hardware... you might consider a "hook" system to pass command line options to some other specified software. For instance... pass a bunch of pre-specified arguments to a sample python method and let the user create their own stuff within that method. For instance pass romname, emulator name, orientation, etc. Whatever data you have to work with, pass along.

That would help beyond rotation, joysticks & led lighting. Most any hardware or software that take command-line arguments could be incorporated at that point.

[DaOld Man]

Rather than direct support for usb hardware... you might consider a "hook" system to pass command line options to some other specified software. For instance... pass a bunch of pre-specified arguments to a sample python method and let the user create their own stuff within that method. For instance pass romname, emulator name, orientation, etc. Whatever data you have to work with, pass along.

That would help beyond rotation, joysticks & led lighting. Most any hardware or software that take command-line arguments could be incorporated at that point.

I think Attract Mode for Pi will do that already.

[mahuti]

One benefit of RGBCommander is that it has it's own huge list of game configurations already, and as he said it already has all the orientation stuff in it. Whereas Attractmode would either need to read from emulator supported metadata, or your own custom crafted stuff. I'm not saying it's not possible, just saying RGBCommander has a good head start for handling user-configured stuff.

My main point is: RGBCommander kicks ass. There are other things I wanna do to my cabinets... it would be cool to have RGBCommander as a base for them.

[DaOld Man]

One benefit of RGBCommander is that it has it's own huge list of game configurations already, and as he said it already has all the orientation stuff in it. Whereas Attractmode would either need to read from emulator supported metadata, or your own custom crafted stuff. I'm not saying it's not possible, just saying RGBCommander has a good head start for handling user-configured stuff.

My main point is: RGBCommander kicks ass. There are other things I wanna do to my cabinets... it would be cool to have RGBCommander as a base for them.

Link?

[PL1]

One benefit of RGBCommander is that it has it's own huge list of game configurations already, and as he said it already has all the orientation stuff in it. Whereas Attractmode would either need to read from emulator supported metadata, or your own custom crafted stuff. I'm not saying it's not possible, just saying RGBCommander has a good head start for handling user-configured stuff.

My main point is: RGBCommander kicks ass. There are other things I wanna do to my cabinets... it would be cool to have RGBCommander as a base for them.

Link?

Announcement thread: http://forum.arcadecontrols.com/index.php/topic,153682.0.html

D/L site: http://users.telenet.be/rgbcommander/


Scott

[ZoOl007]

Hi,

I added an output hook system to RGBcommander. It allows for user designed extensions.

I also finished monitor rotation using the output hook system.
RGBcommander now knows 36540 mame roms  and will just rotate whenever it needs to if the option is enabled.
It also supports rotating other emulators and the frontend if it is configured to do so.

The output system should prove to be very flexible and as user friendly as possible. It is an advanced feature though.

I have only tested it on debian amd64 - not on the pi - but I just expect it to behave as designed.

kind regards

[mahuti]

By the way ZoOl007 I meant to tell you: "VERY COOL!" I lost track of which post had your update in it and it slipped my mind for a few days. 

This is really awesome.

I have another led-wiz being shipped, with some plans to do some cool stuff with it on my Space Encounters machine. No rotating monitor, but the Marquee is a translucent plastic that originally had a red lightbulb behind it that flashed the plastic, and above the monitor itself. The game itself is pretty much crap, but the machine is really cool. It had the red bulb, and a bank of lights in front of the monitor. I plan to use the ledwiz to light these back up again. Since there's no hook system going to have Mame games interact with extra hardware, I won't be doing anything to recreate the original function, but I will be at least making some cool lighting effects for that bank of lights and the overhead.

I'll be experimenting...  who knows, I might use your new output system to handle some custom stuff for this. In any case, RGBCommander is going to bring some real life back into this cab with or without the output system.

[ZoOl007]

thx.
I've added the output system's documentation in the 0.4.0.2's xml.
I think you'll quickly figure it out but if it is not clear or if you have a different approach in mind or need more data from the daemon contact me by mail if you will.
Feel free to update the docu.
regards.

[Mike A]

That is a snazzy cabinet.

[takoni]

Hi, i am a new user, thanks for accept me and sorry about my poor english. I am working in a project, i have the rotating system running with button....




I will like to make rotating from rasp running attrack mode and retropie.... i have all vertical roms but i dont know how to make all this about....   i am not a tech man , not code man ..... sorry.

Thanks.

[DaOld Man]

Hi takoni, welcome to the board!
I was working on a script for RPi that would work with emulation station and used a text file with the 90 degree games in it to trigger mrotate for Pi to turn on associated GPIO pins, which would turn on the drive to run the motor.
I didnt see a lot of interest in it so I shelved it.
Looks like Zo01007 was working on a front end that would turn the monitor, you might want to check out his posts.

[takoni]

Thanks a lot!! i still working on my project, itīs about to become a true ....

I am rotating screen with a button when a game is vertical, by default, when i press ESC to go out a game the creen rotates to horizontal, but i am going to investigate what you are telling me in that post.

Thanks a lot again. Cheers.

[ZoOl007]

Hi,

I just read this post hence the late reply. Seems like you have a script that rotates your monitor. RGBcommander has an output hook system. If you trigger (or put) your code from/in that output script than RGBcommander will automatically rotate everything the correct way for everything that you launch.
You can also customize the behaviour for other emu's.

regards