The Craftmans Shop > Radio Control Models

Bruder Manitou 2150 - RC conversion

<< < (18/19) > >>

For the outrigger limit switches, could you get by connecting all the limit switches of one outrigger in series and only using one Arduino input for the three of them?

Since the Arduino already knows (approximately) where in the range the outrigger is and in what direction it is moving, it should be able to deduce which of the three limit switches was hit. This does require some minor housekeeping in the software, but if it prevents the need for a Mega it might well be worthwhile.

The tricky situation would be if the SW crashed and needed to restart or if it would be starting up after an improper shutdown and any of the limit switches was active at that time. In this case it would need to halt and you'd manually have to solve the situation... In normal operation it would always need to back away from a limit switch right after hitting it: i.e. when retracting and hitting the limit switch the motor would need to spin the other direction for a short while to de-activate the limit switch before parking the outrigger; the same when leveling up or down.

You have a nice project going here!


You might be onto something there.  I can see a couple of problems with that, but they can be solved.

1) What if the unit gets powered down with the outriggers not "Homed" - fully raised and fully retracted?  I can see a couple of solutions:
a - If the Arduino has non-volatile memory that can be accessed, store a Direction bit for each outrigger's extension/retraction and raise/lower.  I'd planned on using these direction bits anyway, so the Arduino will know what it's supposed to do when it sees a limit.
b - Probably the simplest solution would be to have a routine that will Home the outriggers on power-up - similar to what you suggested.

2) Second potential problem I can see with a single input would be during the outrigger raising/retracting cycle.  If I raise and rectact at the same time, I could potentially hit both limits at the same time.  I can see a couple of ways around this problem.
a - Completely the cycle on one of these, then do the other.  This is the simplest solution, but the slowest.
b - I can see a way to retract and raise the outriggger at the same time, and do it safely.  The outrigger extension will be single speed.  Or at worst case 2 speed, and they will move fairly slowly.  The screw is an M3x.5, the outrigger maximum extension is about 75mm, and the gearmotors run at 100rpm - it should take about 1-1/2 minutes to go from fully extended to fully retracted at full speed.  The minor houskeeping in the software that you mention will be keeping track of the time from fully retracted until the pad touches the ground.  For instance, if the outrigger extends for 55 seconds before it touches down then it would be safe to retract the outrigger for 50 seconds, while raising the outrigger at the same time.  The outrigger would then wait while the raise cycle was completed, at which time it would fully retract.  I believe that the raise/lower gearmotor runs at the same speed, will use the same thread on its' screw, and its' maximum extension is 27mm - so if the default extension if the outriggers is far enough, the raise cycle should ALWAYS complete long before the ourigger would be near the fully retracted limit.

You just saved me 9 I/O pins and maybe a bunch of wiring.  There's actually a lot uf unused volume inside this thing.  There are a lot of cross braces to keep a kid from crushing it but for the most part they can go.  Unless I do something REALLY stupid with this model I should be safe getting rid of a lot of the cross bracing.

Maybe I actually can run this thing with Nano's, in a Master/Slave setup.  I've already got a slip-ring for the rotating part of this beast and I think it's 12 circuit.(At least 6 circuit.)  That way I'd use a master to handle the communications with the radio, a slave in the rotating section, might want to use a slave in the upper main frame to handle the lights and slew motor ESC and outriggers.  The master would be in the lower frame and could also handle the steering and drive motors.  OOOOHHHH, this is gonna work out better than I thought.  Might need to go with an Uno in the upper frame - there's a lot of lights.

I've got plenty of room in the counter-weight to stash a slave controller for the rotating portion.  The rotating portion controls will consist of boom raise/lower ESC(And limit input.), boom extend/retract ESC(And limit input.), fork up/down tilt ESC(And limit unput.) a winch ESC, and a flashing beacon.

The upper frame controls will be the slew motor ESC, headlights, tail-lights, and turn signals.  To get brake-lights I need separate turn-signal outputs for each corner.  That's a minimum of 6 outputs for lights, 7 if I use hi-lo beams.  I almost forgot about the outriggers, this is where it coulld get ugly.  Using the brute force approach I'd need 8 PWM outputs for ESC's and 4 limit inputs, just for the outriggers.  Using a slightly more elegant approach and switching between the front and rear outriggers - that drops to 4 ESC's, 2 limt inputs, and at least one output to do the switching.  I've got a lot of usable volume in the in the upper frame, but not THAT much - I've still got to get a battery pack in there somewhere.

This thing is 4WD, and 4 wheel steer, can a Nano handle 4 PWM signals, left side ESC, right side ESC, front steering servo and rear steering servo?  I'm liking this, using an Arduino for this will make switching between normal steering and crab steering SOOOO easy.(With a 6 channel radio - 10 with open source upgrades - I had given up on the ability to crab steer.)

All the gearmotors, even the winch, are N20's - so even an itty-bitty 10A ESC is overkill for them.



May help with the limit switches


(i2c expander - 16 io pins on the i2c bus for future searches when the ebay link expires...)

You could monitor/limit current on the leg motors and detect end of travel by stalling.  Maybe with something springy in there for a little reaction time ;-)

Sent from my SM-G892A using Tapatalk


--- Quote from: WeldingRod on October 09, 2021, 02:46:21 PM ---You could monitor/limit current on the leg motors and detect end of travel by stalling.  Maybe with something springy in there for a little reaction time ;-)

--- End quote ---

I'd thought about doing that, but all the current sensors that I could find were rated for 1-30A.

The motor info that I could find for the N20/GA12 gearmotors suggests a running current somewhere in the range of 0.04-0.1A and a stall current of somewhere between 0.2-0.67A.  I'd need a current sensor that's an order of magnitude more sensitive than what I've been able to find.

The other isssue I had with the current sensor was that I only have a hard stop in one direction of travel.  I haven't been able to figure out a way to have a hard stop in the other direction.  At least I haven't come up with a method that would be reversible when repairs are needed, and still be within my somewhat limited capability to make.



[0] Message Index

[#] Next page

[*] Previous page

Go to full version