Author Topic: Bruder Manitou 2150 - RC conversion  (Read 27840 times)

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #25 on: December 05, 2019, 01:02:21 PM »
I ordered some more stuff last night, an assortment of 5 colors of both 3mm and 5mm LED's, a couple of Arduino Nano development kits, and a couple extra Nanos.  It's Christmas time, cut me some slack.

I used to program PLC's in industrial control systems as a living for many years.  That was, I did the programming until the higher-ups decided that I should have minions to do the programming and that I should be sure they did it right.  I don't even remember how many programming languages I've learned over the last 30+ years, but I can handle one more.

I've never done any Arduino programming, but I know that I've used it, one of my 3D printers is a Prusa clone and is running on a version of Marlin.  I think that I've come up with a way that I can use an Arduino Nano to monitor 2 of the receiver channels and operate some lights in a mostly realistic manner.  As Baldric would say, "Here's my clever plan M'lord."

I believe that a Nano has 14 digital I/O pins that can be configured as either inputs or outputs.  I'll be using 2 pins as inputs to monitor the 2 receiver channels.  That leaves me with up to 12 digital pins that I can use for outputs, that's a lot of different lights.  The maximum load for a Nano output channel is 40 mA, but 20 mA is recommended.  That 20 mA will happily drive most LED's, just gotta' remember to use a current limiting resistor or we're gonna' let the MAGIC SMOKE out of something.  I've found that using an Arduino to monitor an RC channel is a fairly trivial thing to do.  The typical RC system uses a separate pulse for each channel and these pulses will vary in length from 1-2 milli-seconds, depending on the transmitter's stick position.  There's lots of open-source Arduino sketches out there on the ole' Interweb to do the monitoring, just grab one, copy, paste and edit.

I'll use the Arduino to monitor what would be the aileron and elevator channels for an RC airplane.  For this model I'll use the aileron channel to control left/right steering and the elevator channel to control forward/reverse direction and speed.  The way I figure it, by monitoring these 2 channels I'll be able to get semi-realistic operation for these lights:
Work lights
Headlights/Tail lights
Brake lights
Turn signals
Back-up lights
Rotating warning beacons

Work lights - This one will be the least realistic.  If the power is on, and the transmitter's on, and there's no forward/reverse motion, then turn on the work lights.  You don't really need the work lights on if you are inching the unit into position, or moving the unit from site to site.  I suppose that I could add a daylight sensor into this too, I've got a few I/O pins to spare yet.  Don't need no work lights if it's high-noon.

Headlights/Tail lights - If there's forward/reverse motion, then turn on these lights.  Day-light don't matter, like the Wal-Mart drivers - Lights On for Safety.

Brake lights - It there is forward/reverse motion, and if the absolute value of the speed decreases X amount, and the turn signal is off (or if the turn signal is on and the blink is on), then turn on the brake lights for a short time?  The X amount of decrease should keep the brake lights from turning on due to normal noise in the system.  I'll make this brake light time on a variable that I can play with until it feels right, probably start it at about 1-2 seconds.

Turn signals - If there's forward/reverse motion, and if the speed is greater than X, and the left/right stick is not centered, and blink is on, then turn on the appropriate turn signal until the stick is centered.  The "blink" will allow me to use one set of timers for ANY light that needs to blink at the same rate.  I'm using the speed variable to keep the turn signals from being turned on at low speeds.  I've rarely seen turn signals used in a construction site. This logic will also take into account whether this is a front turn signal where I will need to turn on/off a separate light, or the rear turn signal where I will need to turn on/off the appropriate brake light.  The biggest glitch that I can see in this one is that you won't be able to signal your intentions.  Instead you'll be that irritating guy the turns on his turn signal AFTER he's started turning the corner.  Definitely won't pass driving school.

Back-up lights - If direction is reverse, the turn on the back-up lights.

Rotating warning beacons - I'll use these to indicate when the unit is traveling at speed.  If there is forward/reverse motion and the speed is greater than X, turn on the beacons.

Any better ideas?
Don
Too many irons, not enough fire.

Offline kayzed1

  • Sr. Member
  • ****
  • Posts: 294
Re: Bruder Manitou 2150 - RC conversion
« Reply #26 on: December 05, 2019, 02:45:33 PM »
That sounds very interesting :zap: :clap: well that would be the outcome of me trying to do it.. Hydraulics and mechanics are ok but those little electronicy thingies...

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #27 on: December 05, 2019, 05:30:59 PM »
kayzed1:

With me it was the other way around, hydraulics and pneumatics baffled me.  Then I started to think of them as electrical/electronic circuits.  Now I can find my way around in either, but I also know when to throw in the towel and talk to a pro.

Besides, these Nanos are almost dirt cheap.  So if I let the magic smoke out of one or two, I'm not out that much.  They will be run either from the 5 volts that's available on a USB for testing, or from a 2S Lipo battery pack in the model at about 6-7 volts.  If I throw a 1/4 amp or 1/2 amp fuse in to protect the wiring not too much can happen, other than a little smoke that will smell REALLY bad.

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #28 on: December 09, 2019, 02:49:46 PM »
Some neat stuff vitally important material arrived over the weekend, I got my 6 position 2 pole rotary switches from Digi-Key, they're cute LITTLE suckers.

I designed a bracket that will hold a sub-micro servo and the switch, I also had to design the control arm the servo will use to change the switch position.  The first attempt didn't work out so well, things mostly fit, but I didn't have the switch oriented correctly,  The switch needs to have the number 1 position 60° ccw of vertical for all of the detent positions to line up correctly with the servo throw.  There are 2 flats on the switch that keep the switch body from rotating, and a flat on the switch shaft to properly orient the knob, or in my case control arm.  When I modeled the switch flat on the switch, my calibrated Mk I Eyeballs didn't notice that the flat on the shaft did not line up with the switch detent positions - it's halfway in between.

I'm going to be using 5 positions of the switch and I want the #3 position to be vertical, this will make getting the linkages set up sooooo much easier.  I initially had the bracket 3mm thick, I had 4.5-5mm of available threads on the switch body and the nut is 1.5mm thick so I thought I was in like Flynn.  Not so much, no room for the lock washer.  I also discovered my original assumption, that the flats on the switch body would be enough to properly orient the switch, doesn't exactly work in the real world.  The switch comes with a keyed sheet metal locating ring with protruding tabs that will lock the switch into position.  I didn't think I'd need it, I was wrong.  By the time everything gets tightened down, the switch position can change by 10° or more, this is not acceptable. 

I redesigned the bracket, I cut out a section around the switch opening and rotated that section.  I couldn't figure out a way to measure the angles with what equipment I had.  I guestimated this angle at 10-15°, so I rotated the section 10° - turns out I SHOULD have rotated it 15°.  While I still had it loose from the rest of the bracket, I also thinned this section down to 2mm.  This gives me an additional 1mm of usable threads on the switch, along with the room for the locating ring AND the lock washer.  I also did a couple of other things to improve the print quality and reduce the print time, went from 70 minutes to 59.

I discovered that I couldn't get a programmer to modify the digital servos I had.  I had a couple of cheapies that I got from HobbyKing a couple of years ago - go figure.  So I ordered a couple of Hitec HS-5055 sub-micro's and a programmer to match.  They SHOULD be a drop in fit in the bracket.  If not, well, it's not like I haven't re-designed this bracket a couple of times already.

I also got my spool of "Translucent Red", and I'm a little disappointed, this stuff is more transparent than translucent.  I think you could print fairly respectable tail light lenses with this stuff.  The search for a redder red filament was on - again.  I found one that the reviewers consistently said was the "reddest red" they ever seen, and it's called...  "Enzo" Red, yup, it looks like Ferrari Red on a spool.  We'll see how close it comes to matching the Bruder red plastic.  If this one doesn't work, then screw it -  I'm just gonna get a can of rattle-can red and paint everything to match.

I'll take some pictures tonight, after I've got the switch oriented correctly.

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #29 on: December 10, 2019, 03:43:39 PM »
I took some pictures last night and kept the best two, they are attached below.  You've got a view of the actuator arm side of the switch, and the pins side of the switch.  The actuator arm is in the #3 position.  Positions 1 & 2 are CCW of center, and positions 4 & 5 are CW of the center #3 position.  A quarter is shown as a scale reference.  The servo shown is one that I had in my junk box, but it's supposed to be the same size as the Hitec servos I've got ordered.

This will probably be the last of the pictures for a while, I got my Arduino Nano's last night so I'll be busy learning how to program them, doing the programming, and testing/debugging my programming.

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #30 on: December 11, 2019, 12:32:05 PM »
And it just keeps getting better and better.

When I try hooking up to the Nano my set-up for the Com port selection is greyed out.  If I'm understanding what I've found on the Interweb correctly, my Chinese clone Nanos are using a counterfeit communication chip that the driver for the real chip doesn't recognize.  Some kind soul figured this out, and wrote a special driver just for these chips.  I've now got this driver and tonight I'll try loading it.  I'll find out if I can actually talk to the Nano.  All I'm trying to do at this point is get the Nano to blink the built-in LED.  That's the Arduino equivalent of the "Hello World" program in C++. (Baby steps donchaknow.)

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #31 on: December 12, 2019, 10:27:56 AM »
Well..... It took until after 10:00 last night but I finally got it to run the Blink program, the Arduino equivalent of "Hello World".

I found out many things last night, primary among them is that Google is your friend,

I found out that I DO have the CH340G communication chips on my Chinese clone Nanos and also that not ALL CH340 drivers are created equal.  I had to go through several different drivers before I found one that even appeared to work.  That got me up to the point where the error message was that it couldn't sync up.  Back to the Interweb and Google's still being my friend.

I found out that some chips used 57600 baud and others use 115200 baud.  Wait a minute, I"VE got to set the speed?  I've gotten spoiled by software packages that do the minion work for me.  Oh well, we'll do this the hard way, what's my serial port set at?  9600 baud, NOBODY's used 9600 baud for years and years.  We'll try 57600 and see if that works... No Joy, let's try 115200....  And EUREKA, I got a different error message!

This time it's telling me the programmer's not responding.  Back to the Interweb and Google's still being my buddy and pal.  It seems that some Chinese ATmega328s are being shipped without bootloaders, one of the reasons they are so cheap.  WTF, do I NEED a bootloader?  How do I get one if I do?  Turns out I can use a Nano to burn a bootloader on another Nano...  As long as I've got a working Nano - so that option's out.  Does it seem like I'm stumbling around in the dark here?  If so, you're absolutely right.  A little more research and it seems that you don't really NEED a bootloader if you set up the IDE programming software correctly.  Go through and check the appropriate boxes and... NOPE, still doesn't work, programmer is STILL not responding.

Back to the Interweb, and while Google is not being my bestus Bud anymore, he still kinda likes me.  It seems that while some Chinese ATmega328s are shipped with the NEW bootloader, some are still shipped with the OLD bootloader.  And guess what, there's an option in the software for an ATmega328 with the OLD bootloader.  OK, we'll give it a shot, if this doesn't work I'm goin' to bed!!….  Ah - VIOLA, "Hello World", I have a Nano with a blinking green light, on for a second, off for a second and repeat 'til I tell you to quit.  Just like the program says - it's bedtime.

Tonight I'll start picking away at getting it to do what I want it to do.  Is an Arduino always this much fun getting the communications set up?

Don
« Last Edit: December 12, 2019, 04:07:34 PM by ddmckee54 »
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #32 on: December 13, 2019, 10:54:16 AM »
I found out a few things about the Arduino Nano, and the Arduino programming language last night.  If you're not interested in programming, mostly just the basics, then you probably want to just skip to the end.

I set up a simple input/output program and the hardware to match it.  I declared a couple of digital pins to be inputs and a couple more to be outputs.  Then wrote a conditional statement - If the X input is on, then turn on the Y output.  Easy-peazee right - not so much.

I found out that this programming language is REALLY case sensitive.  For instance, I can type pinmode(), or pinMode(), and some languages will recognize that I want the pinMode() command.  (Declaration?  It's been too many years, and I had trouble keeping them straight in college.)  But NOOOOO...., not this one.  It took me a while to figure out what the "pinmode not declared" error message was actually trying to tell me.

A little lesson in binary, and integers, and other fun stuff.  Binary is all 1's and 0's right?  Ummm…. no so much.  A binary condition will either be HIGH or LOW, right? Those statements are the same, right?  In some programming languages you can get away saying 1 is equal to HIGH, and 0 is equal to LOW, but not this one.  I had declared Ch_1 as an integer variable and did a digitalRead(2, Ch_1).  I assumed that this would put a value of 1 into Ch_1 whenever the digital pin 2 was at +5V.

My conditional output was this; if Ch_1 is equal to 1, then turn on the output.  I got nuthin'.  I jumpered the LED to +5V and the LED came on, so I knew the hardware worked.  The problem was in the programming, but where?  I even tried to use the built-in LED - no difference.  It's been 20+ years since I did any electronics design and I am a LITTLE rusty.  I was figuring that I screwed up somewhere, but since I could jumper it and it would work then apparently I had got the hardware right.

Then I started wondering, since this is a digital input, maybe it assigned a Boolean value to the digitalRead()?  OK, let's try that. Declare Ch_1 to be Boolean and the digitalRead(2, CH_1) stays the same.  But the output condition changes to this -  if Ch_1 is equal to HIGH, then turn on the output.  Try it again, and SHAZAAM, the output comes on.

Wait a minute, why isn't it turning off?  A couple of seconds later it turned off.  WTF is going on here?  After scratching my head for a while, I've been in this industry since the 70's and I've scratched most of the hair away, I started wondering if I needed to add pull-up or pull-down resistors?  Google is my buddy once again, and I find out there's a version of the pinMode() declaration that will activate the built-in pull-up resistors on the digital pins used for inputs.  Since the pin is always HIGH now, I've got to jumper the pin to 0V to test my programming and invert the output conditions.

Download the updated program, test it, and HOT CHACHACHA...  I've got control of an LED, and it only took me how long???  Holy-Crap, it's past my bedtime.  Time flies when you're having fun?
Don
 
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #33 on: December 16, 2019, 05:02:35 PM »
I did something stupid over the weekend, I broke my communications between the Nano and my PC.

I'm not sure how I did it but somehow the wrong drivers got loaded and now it won't talk anymore.  I think I may have plugged it into the wrong USB port, and that's what started this mess.  I saw that instead of the CH340 driver on COM5, I had the Ramps driver on COM4.  The Ramps driver is what the IDE software will load when it detects a Nano on the USB.  The only problem is that the Ramps driver is for the FDTI chip and I've got the CH340G chips on my Nanos.

I reloaded the driver that I thought worked but now no joy.  Back to the Interweb, and hope that Google still likes me.

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #34 on: December 18, 2019, 03:48:27 PM »
Once again I'm beyond the "Hello World" stage, not much to see except a couple of blinking lights.

I discovered a couple of things:

If I disconnected the communication cable at the PC end nothing bad happened.  If I disconnected the cable at the Nano end, the IDE software loads the Ramps driver for the COM port.  This is onna-conna that Ramps has the FTDI drivers in it and that's what Nanos are SUPOSSED to be using since a real Nano uses the FTDI chip.  Except that I've got Chinese clone Nanos with the CH340G chip, and I need the CH340SER drivers.  (Note to self - NO more disconnecting the Nano without FIRST disconnecting the cable from the PC!!!)

One other thing I discovered is that I've got 2 different flavors of Nanos, which kinda makes sense  - since they were from 2 different suppliers.  They both have the CH340G chip, but one type of Nano requires the "Old" style bootloader at 115200 baud, and the other type of Nano requires the new style bootloader at 128000 baud.  Oh frabjous day...

At least I know what I did wrong, and how to fix it  - now.

Now that I've got the communication going again, I'm back on track and I've got a bunch of logic tested and de-bugged.  I've got the NANO set up on a bread-board with outputs for headlights/tail-lights, left front turn signal, left rear turn signal, strobe/beacon, and back-up lights.  I've got digital inputs for moving (Yes/No), turning left(if we're not turning left we gotta be turning right), brakes(Yes/No), and direction(For/Rev).  The brake lights, rear turn signals on steady, are currently being triggered off a digital input, when I get the R/C logic working this will be changed.  I'm planning on looking at the average value of the For/Rev stick pulse.  If the speed, either forward speed or reverse speed, is decreasing then the brake lights will be turned on for a couple of seconds.  When I'm turning and the brakes are on, I flash the appropriate rear turn signal off instead of on.


I haven't got the R/C receiver pulse logic done, that's the next step.  I HAVE got the logic done that looks at the pulse length values for the for/rev channel and the left/right turn channel, and then decodes this for the various LED functions.  I won't bother with the right turn signals until I start putting the lights on the model.  The RH turn will just be a copy/paste/edit of the LH turn-signal logic. 

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #35 on: December 19, 2019, 01:31:10 PM »
I did a little more testing and debugging last night.  I've got the programming working correctly on all the LED functions except one, the rear turn signal.

The rear turn signal is a red LED that does double duty, it is on steady when braking, and it flashes when turning.  The turn signals flash on for 250 milli-seconds and then are off for 750 milli-seconds.  If we're still turning when this cycle is complete, then the cycle is repeated, and repeated, and repeated - just like that old guy you followed that had his turn signal on for 5 minutes. The brake lights are a cycle that is triggered by a speed set-point reduction.  They will be turned on for about 4 seconds and then turned off.

What about if you are turning and braking?  Funny you should ask, that's the one that isn't working correctly.  When braking and turning, the rear turn signal is flashed, off when the front turn signal is on and on when the front turn signal is off - so that the light is on more than it is off.  At the end of the braking cycle the rear turn signal is SUPPOSED to sync up with the action of the front turn signal.  Sometimes the rear turn signal will complete the braking cycle and sync up with the front turn signal - just like it's supposed to do.  Sometimes it stays in the braking cycle WAYYYY longer than it supposed to.  And sometimes it completes the braking cycle, syncs up, and then eventually resets itself and starts the whole thing over again.

Somewhere I did something stupid and I've got a race-condition/timing issue. I think what's happening is sometimes it's event A before event B, and sometimes it's event B before event A.  I just need to find my Boo-Boo and fix it.

Don
Too many irons, not enough fire.

Offline Pete.

  • Hero Member
  • *****
  • Posts: 1075
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #36 on: December 19, 2019, 01:53:16 PM »
Isn't there some kind of gui that you can point and click and it will spill out code for the nano? That all seems like a whole lot of effort.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #37 on: December 19, 2019, 03:48:46 PM »
Pete:

GUI, not that I know of.  There's similar stuff out there that I could copy and paste, but where's the challenge in that?  Just yesterday I stumbled across a thread in rctruckandconstruction.com of a guy that was doing something similar with a Nano.  But I've always wanted to learn how to program an Arduino, and this gave me a perfect excuse reason to do it.

Don
Too many irons, not enough fire.

Offline AdeV

  • Madmodder Committee
  • Hero Member
  • *****
  • Posts: 2434
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #38 on: December 19, 2019, 06:06:32 PM »
Hi Don,

Interesting work with the Nanos... would you be prepared to show your code? I'd be interested in how you've achieved your various functions.

I've done a few bits and pieces with Arduinos (including Nano and Mini Pro sized boards, both with/without FTDI and/or USB interfaces); I'd probably work this one as a finite state machine, or more likely as a set of FSMs - one per function, or one per light, whichever worked out easier.
Cheers!
Ade.
--
Location: Wallasey, Merseyside. A long way from anywhere.
Occasionally: Zhengzhou, China. An even longer way from anywhere...

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #39 on: December 20, 2019, 11:31:27 AM »
AdeV:

When I've got the code working, I plan on posting it.

This isn't my first programming rodeo, I've been programming PLC's for 30 years.  However this IS my first rodeo programming Arduinos.  Consequently, the programming will have more brute force than eloquence.  I find myself thinking of the programming in terms of a PLC's ladder logic programming, and then converting that in my head to something the Nano can understand.

Let me ask you this, what do know about the timing of the pulsein function?  I'm not sure, but from what I read it sounds like if I tell the Nano to do a pulsein on a particular digital pin, it's going to sit there and wait until it sees that pulse.  Program execution basically stops?  Does program execution also stop during a delay, like I think it does?

If that's what happens then I can see why everyone says you should use interrupts instead of the pulsein function.  At 2 milliseconds per channel, when you add in some time separation between channel pulses, and some time at the end so the receiver knows there's a new pulse string coming - then we're looking at a 20-30 millisecond time for a complete pulse string.  That's a longggg time for the Nano to be sitting there twiddling it's proverbial thumbs.

Don
Too many irons, not enough fire.

Offline russ57

  • Sr. Member
  • ****
  • Posts: 278
Re: Bruder Manitou 2150 - RC conversion
« Reply #40 on: December 21, 2019, 04:52:18 PM »
Delay certainly executes a loop. Not sure about pulse in, I've not used that.
Pulsein long notes it uses interrupts, so that may be better.
If you are looking for pulses on many pins you may be better writing your own routine.



Russ


Offline AdeV

  • Madmodder Committee
  • Hero Member
  • *****
  • Posts: 2434
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #41 on: December 22, 2019, 05:44:20 AM »

Let me ask you this, what do know about the timing of the pulsein function?  I'm not sure, but from what I read it sounds like if I tell the Nano to do a pulsein on a particular digital pin, it's going to sit there and wait until it sees that pulse.  Program execution basically stops?  Does program execution also stop during a delay, like I think it does?


Can't say I've ever used pulseIn - I'd have to go read up on it. Delay certainly stops program execution, and IMHO is to be avoided at all costs (except in the very very simplest of applications).

If that's what happens then I can see why everyone says you should use interrupts instead of the pulsein function.  At 2 milliseconds per channel, when you add in some time separation between channel pulses, and some time at the end so the receiver knows there's a new pulse string coming - then we're looking at a 20-30 millisecond time for a complete pulse string.  That's a longggg time for the Nano to be sitting there twiddling it's proverbial thumbs.

I guess it would depend on whether the Nano has other stuff to be getting on with, whilst it's waiting on pulses to come in. If there's literally no processing except when a pulse is received, then a blocking operation is OK. I suspect that isn't the case, so yeah, you'd be better off using interrupts. The usual rule is, keep your interrupt processor as tight as possible (this usually means incrementing or setting a variable only), and let the main loop pick up the fact it's changed. That's why I try to do FSM style programming on Arduinos, so the main loop can run around quickly, which makes it responsive to changes of state. The interrupts are what trigger the new state.

Gotta go, visitors arriving.
Cheers!
Ade.
--
Location: Wallasey, Merseyside. A long way from anywhere.
Occasionally: Zhengzhou, China. An even longer way from anywhere...

Offline kayzed1

  • Sr. Member
  • ****
  • Posts: 294
Re: Bruder Manitou 2150 - RC conversion
« Reply #42 on: December 22, 2019, 01:45:51 PM »
AdeV, if knock on door=visitor then GoTo door :thumbup:

Offline AdeV

  • Madmodder Committee
  • Hero Member
  • *****
  • Posts: 2434
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #43 on: December 23, 2019, 02:05:46 AM »
So.... this morning, whilst waiting for my brain to warm up, I had a quick read of pulseIn and pulseInLong - and it does look like they are blocking calls.

A quick google around showed a few options; my go-to option would be to use interrupts. In the interrupt handler, simply set a variable to the current value of the clock (IIRC micros()), and possibly a variable showing whether the pin went high or low (although you could do that in the main loop). Then, in the main loop, examine the clock variable & compare to your last known variable; if it's changed, either a pulse just started, or just finished; either way, process as applicable.

Another option - useful if you're not bothered about getting precise pulse timings, and you've got a fairly tight main loop; is simply to scan the pin states on every loop & process accordingly. However, you definitely don't want to use digitalRead() for that - it's too slow. There's a register you can examine directly which will give you the pin states without all the overhead; I can't remember what it is off the top of my head, but a bit of googling should give you the answer. The nice thing about that is you can read all the pin states in one op; then either spin through them using a bit shift, or even do a bitmap comparison for patterns of interest.

Either way - lots of ways to skin that particular cat! (poor cat)
Cheers!
Ade.
--
Location: Wallasey, Merseyside. A long way from anywhere.
Occasionally: Zhengzhou, China. An even longer way from anywhere...

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #44 on: December 23, 2019, 04:23:47 PM »
I'm only going to be monitoring 2 channels, and all I care about is the width of the channel pulse in micro-seconds.  By the very nature of the RC channel pulse train, those pulses can NEVER occur at the same time so I can use brute force on this and have these 4 interrupts:
Channel 1 rising - record the current program time in microseconds
Channel 1 falling - calculate the channel 1 pulse width in microseconds
Channel 2 rising - record the current program time in microseconds
Channel 2 falling - calculate the channel 2 pulse width in microseconds
If the pulse width value is less than 1000, I'll just shove 1000 in for the pulse width.  That way I don't need to worry about what's going to happen when the program time rolls over in the middle of a pulse.  Eazee-Peazee.

I got my assortment of "robot" parts over the weekend, I'm now the proud owner of a variety of gears, all in Mod 0.5, with bores of 2mm, 2.5mm and 3mm.  Along with some mostly useless pulleys, wheels, and I think they're supposed to be paddle-wheels?  My slow boat from China also brought me my slip-rings.  The bottom line, I was working on the design for the slew drive over the weekend and I've just about got it done in CAD.  If I've got my numbers right, I'll be able to slew the cab at a little over 2 rpm at full speed - which I think is about right?
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #45 on: December 24, 2019, 02:15:33 PM »
I just about got the design for the cab/turret slew drive done last night.  I thought I was done, until I realized that while my turret drive gear has 6 reinforcing ribs in it's design, the turret base actually had 8.  Silly me, I had ASSUMED that they both had 6.  Fixing the 3D model took a while, and it sort of hurts when you have to throw away a perfectly good design - just because it's WRONG.

On to bigger and better, or at least different, things.  I'm going to use the 9 channel Turnigy transmitter and 6 channel Turnigy receiver that I've got, which are currently laying around doing nothing.  They were both low cost units so I don't feel too bad about tearing into the transmitter to replace the current 5th and 6th channel inputs with my 5 position switches.  I think that currently one is a 2 position switch for retracts, and the other is a variable pot.  My digital servos and programmer also arrived last week, so once I get this easy stuff out of the way, I've still got those 5 position servo selectable switches to deal with....  Oh Frabjous day!

I keep getting the "Switch in wrong position" error on power up of the transmitter.  I need to Google that error again, I know that there is a specific combination of switch settings this transmitter needs on power up - or it pukes out the error message.  This time I'm gonna make a tag of the correct settings and stick it to the transmitter.

I'll get the transmitter talking to the receiver, and the receiver talking to the Nano, then I can use the Nano to decode the desired receiver channel pulse widths into the light controls - EAZEE-PEAZEE.  Or so I've been told.

For my two 5 position servo selectable switches, I'm going to use the 5th and 6th channels to set the selector switch settings.  I'm then going to use what would normally be the Rudder stick to control one of  the ESC's, and the modified Throttle stick will control the other ESC.  I'm also going to need to see what I need to do to make the throttle stick self-centering.  My 5 position selector switches have 2 center poles, and with a separate ESC wired to each switch, this allows me variable-speed directional control up of to 5 different motors with each switch.  This way I'm not trying to send servo signals through the slip-ring, just 6VDC motor power that's well within the power limits of the slip-ring and is not as susceptible to electrical noise.  Even though the slip-rings were designed for instrumentation, CCTV and camera gimbal controls, I don't want to push my luck.

Don
Too many irons, not enough fire.

Offline AdeV

  • Madmodder Committee
  • Hero Member
  • *****
  • Posts: 2434
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #46 on: December 24, 2019, 06:26:02 PM »
You can only service two interrupts on the Nano, and you can only have one ISR active per interrupt - although you can swap it in code, which is pointless because it's pretty easy to use the CHANGE type, and use the ISR to reset the time if the pin has gone HIGH, and record the time if it's gone LOW. So long as your main loop can get around to reading them before the next pulse arrives, you're good to go. Remember that the value from MICROS() wraps fairly frequently (every ~72 minutes, according to a post I read on the Arduino.cc forums), so your best bet is to use a "start time" variable (on rising edge) and an "end time" variable (on falling edge); subtracting the former from the latter will ALWAYS give you the correct number of microseconds, thanks to the magic of binary logic - so no need to worry about the clock rolling over.

A third (boolean) variable could be used to indicate that a pulse is "in progress", so you don't accidentally subtract the old pulse end time from the new pulse start time during a pulse. I'd have to sit down with an Arduino in hand to figure the logic, but I'm sure you can do that anyway.

I had wondered if you could do some electronic trickery to multiplex the pulses for the interrupt handler; but I guess with 2 channels, it's entirely possible that 2 pulses will overlap, which would give erroneous readings.

If you ever wanted to monitor more than 2 channels, I'd be tempted to set up a timer interrupt at a suitable resolution for your need (100uS maybe, given your statement about setting a pulse width of 1000uS if it came out less than that) which would scan each channel & set/reset the clocks as applicable. Yes, you'd lose a little accuracy, but not so much that it mattered, I'd wager, and you could monitor 8 channels with ease.  Of course.... whether your main loop actually got enough program time is another matter; and I don't know if you can trigger an interrupt on a timer with Arduino; you may need an external trigger for that.
Cheers!
Ade.
--
Location: Wallasey, Merseyside. A long way from anywhere.
Occasionally: Zhengzhou, China. An even longer way from anywhere...

Offline AdeV

  • Madmodder Committee
  • Hero Member
  • *****
  • Posts: 2434
  • Country: gb
Re: Bruder Manitou 2150 - RC conversion
« Reply #47 on: December 24, 2019, 06:37:16 PM »
Hah! A few moments of googling show that timer interrupts are entirely possible on Arduino, although you can/do lose the use of some functions....

Good intro here: https://www.instructables.com/id/Arduino-Timer-Interrupts/

But since you're only doing 2 channels, it's more for academic interest than actual use :)
Cheers!
Ade.
--
Location: Wallasey, Merseyside. A long way from anywhere.
Occasionally: Zhengzhou, China. An even longer way from anywhere...

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #48 on: December 26, 2019, 02:53:30 PM »
Ade:

Thanks for the info, when I started this I didn't know enough about Arduino interrupts to be dangerous,  Now I know WAYYYYY more than enough to be dangerous.  Starting from your link I stumbled upon a discussion of the fast servo library.  There's some good stuff there, it's way more sophisticated than I need for this project, but definitely food for thought.  It gives me a good idea of what I need to do in order to make this work,  And how I need to set up my ISR's.  You've probably saved me a bunch of time and much tearing of hair, something I can ill afford to do anymore.

All I really need to know, is if the steering channel and for/rev channel pulses are centered or not.  They are centered if the pulse is approximately 1500uS long.  Assuming a deadband of ±50µS then then if the value is below 1450µS, or above 1550µS then I know the stick is not centered.  I'm not actually trying to control a servo from the Nano, just turn on a bunch of LED's.  But it's still nice to know that the fast servo library is out there, for use in future projects.

Don
Too many irons, not enough fire.

Offline ddmckee54

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
Re: Bruder Manitou 2150 - RC conversion
« Reply #49 on: January 06, 2020, 04:05:54 PM »
Not too much progress since last time.  In my day job the two busiest times of my year are the Christmas shutdown and the July 4th shutdown.  When the plant's not running, you've got to cram in as much process improvement work as you absolutely can.  The plant's up and running again now so we can all take a couple of deep breaths - and then start getting ready to do it all over again in July.

I did get a little time to do some more work on the turret slewing gearbox.  For a little while I thought that I had it completed, then I turned on the steering servos in my CAD drawing.  The slewing gearbox and one of the steering servos were trying to occupy the same volume of space - not a particularly good idea.  I wound up rotating the gearbox CCW 90° around the turret pivot axis, and letting the gearbox stick out the side of the frame - into the unused space inside the model fuel tank.  That was mighty considerate of them, putting that big, well - relatively big, empty space right where I needed it.

I started printing out the parts for the turret slewing gearbox, when I've got it complete I'll take a family photo and I'll update the 3D PDF.
Too many irons, not enough fire.