Anyone using Arduino for RC?

[Mad Ax 9292]

Anyone using Arduino devices in an RC setting?  What have you achieved, what pitfalls have you uncovered?  Is it as easy as the tutorials etc. say and do you ever have random "why doesn't this build" / "why has it crashed again" issues or are they genuinely quite trouble-free and stable?

I royally avoided the Raspberry Pi hype when they appeared on the market a while back - some friends of mine bought them with the intention of doing something edgy and cool and AFAIK never got them to do anything at all.  IIRC they were quite expensive back then so it seemed like a lot of money and time spent for no result.

I'd heard of Arduino but I thought it would be pricey so I've never looked into it.  That is until I was thinking about some lighting / sound / functionality requirements for my next big rig build, and I decided to see if anyone else had done something similar and what was involved.  Long story short, last night I ordered an Elegoo Mega 2560 R3 and an L298n motor driver, all for less than £20.  Delivery is due tomorrow.

For all the things I've thought I'd do (such as taking inputs from RC receivers, producing sounds, controlling motors) there's already someone doing it.  There's loads of source code online that does a bit of what I want to achieve.  It's all pretending to be suspiciously easy and I'm not sure if I've missed something somewhere.

I did a bit of electronics at college but it was mostly theory work. I remember doing projects on the 741 op amp and the 555 timer chips, I'm pretty sure I had them in a breadboard at one point, but it was all so long ago, I can't remember if we ever saw any live results.

We used some breakout boards at college that used Z80 processors, but they were the size of an ipad and wouldn't fit under an RC shell.  Besides, they were programmed in machine code, and making them do anything beyond adding two numbers and saying "I've added two numbers" by means of an LED (which didn't actually list the value of the added numbers) took hundreds of lines of unreadable code.

Anyhoo, here I am already thinking out loud about what seems possible, and it makes me wonder if the likes of Beier and Servonaut got onto this a while back and that's why they can offer so much programmability in such small packages.  In fact I've wondered if a lot of the electronic stuff on the market now, which used to be very expensive and is now cheap as anything (e.g. light/sound modules), uses Arduino boards or custom boards based on the Arduino design.  There's no complex circuits to design from scratch and no low-level code to write.  Just a bunch of boards made up by the thousand and anyone who knows C++...

I'm digressing.  It occurred to me that I hate how the Tamiya MFU has such a terrible throttle profile, especially for reversing.  In fact I hate how the Tamiya MFU still uses that awful "pull once for brake, twice for reverse with no throttle profiling at all" thing.  Try letting a fully-loaded rig roll down a ramp, you can either use the brake just once and hold it on, or you can use it twice and watch as your rear wheels go into reverse and either jack-knife the rig or reverse it into whoever is coming down the ramp behind you.  But that's OK, I can make my own throttle profile.  In fact I can move to a Beier-style throttle system with FWD/BRK or REV/BRK toggled by a switch or other input.  (OK, I'm not sure yet how to make a motor brake instead of reverse over PWM, that's something to investigate).  I can program my own sound system to use the sounds I want the way I want them.  Alright, I might have issues with available RAM for samples and I'm not sure how many output channels I can use for other effects, but hey...

I'm not sure I want to replicate Tamiya's entire lighting functionality.  That seems like a step too far.  But for my next rig I probably don't even need that - just a simple toggle setup for headlights, maybe a toggle switch for indicators (I hate that MFU-01 indicators only work on full lock and MFU-03 indicators need that little wiggle input to turn them on), and brake lights off the brake input.

I'm guessing the two most daunting parts to any beginner are wiring up the peripherals and writing the code.  Well, I did a bit of electronics in my younger years - I've got a lot to refresh myself on and no doubt I'll blow a few LEDs along the way and maybe even let the magic smoke out of an Arduino chip, but at current prices that's not the end of the world.  And I'm a C# coder by day - nothing I've seen so far in the code samples I've read phases me at all.

I'd love to see what anyone on here has done Arduino-wise.  I'll be sure to update this with my results once I've got my first board plugged in and doing stuff, and I'll add a proper project thread once I've decided what my first major goals will be

[Ray_ve 1043]

I experimented with an arduino. 

Captured the throttle and steering signals, and used this input to set the colors of WS2812 LEDs.

These LEDs can be set to any color and brightness via arduino. So imagine the following:

Tail lights, low intensity red for normal light, bright red for brake. From red to blinking orange for indicators, or white for reverse lights.

front lights, white or blueish cold white or yellowish white, whatever color suits the specific car style.

Side lights, from low intensity white to blinking orange for  indicators.

You can even have the car lighting gradually change color depending on throttle setting.

If anyone is interested, I'll post the schematic and code.

 

edit: Another plan I had was to limit steering angle with increased throttle setting, the Arduino can map this too if you control the steering servo via the arduino. Saves me a programmable transmitter.

[Nobbi1977 1793]

I have one set up as a car ECU. Not a toy car a 1:1 so with the correct program it should be able to do just about anything you want.

 

 

[Mad Ax 9292]

13 hours ago, Ray_ve said:

I experimented with an arduino. 

Great stuff - did you hardcode the transmitter trim values or did you set any way to calibrate it?  I'll probably go hardcoded to start with although my brain is already working out ways to capture the trim settings in a calibration mode.

I like the idea of getting different colours from the LEDs - saves having to mount lots of standalond LEDs and saves some outputs too.

Arduino should arrive today (provided the wife stays in to sign for it or they put it somewhere safe) so unless it ends up back at the PO I'll probably spend all night tinkering!

Once I've run some basic test apps and got familiar with the IDE I'll start writing down the features I want and come up with a plan

10 hours ago, Nobbi1977 said:

I have one set up as a car ECU. Not a toy car a 1:1 so with the correct program it should be able to do just about anything you want.

Awesome - what car, and what is the ECU doing that the stock one doesn't?  Is it your own ECU code or opensource?  I remember there being an opensource Megasquirt ECU a while back when I had my MX5 but IIRC that was a DIY circuit board.  People were using them for turbo conversions in the MX5 community.  I also looked into Megashift a while back as I'd love to be able to set different shift maps for my Elgrand, but last time I looked there wasn't a lot of documentation on the Jatco transmission that it uses.  That said, it probably wouldn't be hard to hook up all the pins on the shift ECU to some LEDs, go for a drive, record what pins light up in what situations and work out where to go from there.  But I've always been nervous that I'll misread something and cause it to do something daft and dangerous while I've driving...

[Ray_ve 1043]

2 hours ago, Mad Ax said:

Great stuff - did you hardcode the transmitter trim values or did you set any way to calibrate it?  I'll probably go hardcoded to start with although my brain is already working out ways to capture the trim settings in a calibration mode.

I like the idea of getting different colours from the LEDs - saves having to mount lots of standalond LEDs and saves some outputs too.

When a RC car is turned ON, the arduino turns ON as well. And typically, throttle and steering are in neutral position at power up. So the program started by capturing the receivers  pulse width output of throttle and steering, and use those values as zero reference for the remainder of the time that the arduino remains powered ON, until the car is switched OFF again.

The blinkers simply use neutral value plus or minus a hardcoded dead-band value before the blinkers turn on. So they only turn on after a specific steering angle, not for minimal steering corrections.

Throttle also turned on the high beam headlights from 75% throttle position to 100%. And reverse position from neutral the reverse lights.

Connections are minimal. +5V power and ground to the arduino. 2 lines to interrupt inputs for receiver throttle output and steering output. 1 data line output to the LEDs, these LEDs also re-transmit the incoming data to the next LED and so on, so they are all connected in 1 series string, +5V, ground, and 1 data line go to the arduino board.

Since the transmitters/receivers I use are pistol-grip whith an extra 3rd channel, this 3rd channel can be used to turn more features ON/OFF.

[Mad Ax 9292]

Thanks for the input @Ray_ve.  I love the calibration setup.  I wondered about capturing max movement values using a setup button but that's for way far down the line.  It's not like I change transmitters often.

When you say the LEDs are on one series string - do you mean you have one string that has all the different LEDs on (brake, headlight, etc)?  If so how does each LED know what its job is - do they have individual IDs of some sort?  Or have I misunderstood?  I've had a very quick glance at a data sheet for the WS2812 but I think I need to look in more detail.

Off the top of my head, the inputs / outputs I'm thinking for the initial build are:

3-position switch for indicators.  I like manual control better than flapping around with the sticks - it looks OK on drift cars etc but on the truck layout I like to be able to indicate before a junction rather than on the way around it.  Plus RC trucks spend a lot of time at full lock with indicators coming on and off, IMO it looks a bit odd.

3-position switch for engine on/off/special.  I love to be able to toggle off the motor and steering so I can walk away from the layout and not worry about my truck taking off.  Tamiya's MFUs have this feature with a two-stick input command (full right left-stick, full-forward right stick).  There's no reason why I couldn't implement a stick command like the MFU but to start with I'll use a toggle switch on the TX.  A 9-channel Tx isn't that expensive now.  Later I can integrate this with the startup / idle sound, if I'm going to go down that route.  The 'special' position depends on what truck I'm designing for, but for example, one of my planned projects will have a 'burnout' mode.  This will use a servo to lift the chassis off the ground slightly so the rear tyres spin.  Well, maybe.  Alternatively it will be a 'park' mode - i.e. disarm the throttle and steering inputs but leave engine idle sound playing, so I can freely play with other truck functions without worrying about it driving off.  That frees up the throttle and steering channels for other inputs, maybe.

3-position switch for gear selection.  Actually I don't care much for the 3-speed gearbox, even with an 80 turn motor most RC truck layouts are too small for anything but 1st gear.  (Always having to hold my left stick full-left is getting annoying so I'll probably unplug the servos on my MFU-equipped trucks before the new season starts).  So this will basically be D,P and R.  In P I can rev the motor as much as I like (the motor SFX will play, if I get that far) but not go anywhere.  In D the truck will go forward on fwd-stick and brake on back-stick.  In R, the truck will reverse on fwd-stick and brake on back-stick.

Brake lights will operate off the back input on the left stick and reverse lights will operate when the gear switch is in R.

A simple push-button or other NO switch can be used to cycle light modes (all off, sidelights + tail lights, headlights + tail lights, fogs + headlights + tail lights) and if I felt like it (although it's not strictly necessary) a separate switch for main beams.  The idea of a quick 'headlight flash' option is appealing so perhaps this channel could have 'push forward to cycle light modes, pull back to flash headlights' functionality.  My (horrible) Carson handset has a non-latching toggle switch that always returns to the centre.  I'm sure I can buy switches like that to replace the latching ones on my Turnigy handset (which IIRC has all latching toggles).

That doesn't use up all the channels on the Tx yet, plus there's loads of scope for altering functionality based on the master mode switch.

I've already written a rudimentary motor control app during my lunchbreak which compiles OK, unfortunately I can't install the Arduino simulator apps here to test it so it'll have to wait until I get home and all the chores are done!

[Ray_ve 1043]

58 minutes ago, Mad Ax said:

When you say the LEDs are on one series string - do you mean you have one string that has all the different LEDs on (brake, headlight, etc)?  If so how does each LED know what its job is - do they have individual IDs of some sort?  Or have I misunderstood?  I've had a very quick glance at a data sheet for the WS2812 but I think I need to look in more detail.

 

The LEDs use 4 pins:

+5V and ground for power

Data in, this comes from the arduino or another LED's Data out

Data out.

The data out pin outputs the previous data of the LED, if the LED receives a new command. That is the trick.

 

Imagine 3 LEDs in series.

LED 1 has Data in to the arduino output.

LED2 has Data in  to LED1 data out

LED 3 has Data in  to LED2 data out

(Etc... Etc.... if you use more LEDs. The test set-up I had had something like 16 LEDs.)

 

In the Arduino program, you define the numer of LEDs, and a name for each LED so you can use names in the program. Much simpler then defining numbers.

When the Arduino wants to set All LEDs to red, it outputs:

1st command LED red. This is now in the first LED.

2nd command LED red, This is now in the first LED, and the first LED outputs the 1st command LED red to the second LED.

3rd command LED red, This is now in the first LED, and the first LED outputs the 2nd command LED red to the second LED, the second LED outputs the 1st command LED red to the third LED.

 

If you want to set the LEDs to Red (LED 1) - Green (led 2) - Blue (led 3):

1st command LED Blue. This is now in the first LED.

2nd command LED green, This is now in the first LED, and the first LED outputs the 1st command LED blue to the second LED.

3rd command LED red, This is now in the first LED, and the first LED outputs the 2nd command LED green to the second LED, the second LED outputs the 1st command LED blue to the third LED.

This all happens so fast, the LEDs seem to output the colors instantly. The delay in the string is very low.

 

Most of the commands are ahndeled by an arduino library, so you do not need to generate the serial data yourself. I'll look up the program, and post it.

[Nobbi1977 1793]

9 hours ago, Mad Ax said:

 

Awesome - what car, and what is the ECU doing that the stock one doesn't?  Is it your own ECU code or opensource?  I remember there being an opensource Megasquirt ECU a while back when I had my MX5 but IIRC that was a DIY circuit board.  People were using them for turbo conversions in the MX5 community.  I also looked into Megashift a while back as I'd love to be able to set different shift maps for my Elgrand, but last time I looked there wasn't a lot of documentation on the Jatco transmission that it uses.  That said, it probably wouldn't be hard to hook up all the pins on the shift ECU to some LEDs, go for a drive, record what pins light up in what situations and work out where to go from there.  But I've always been nervous that I'll misread something and cause it to do something daft and dangerous while I've driving...

The ECU is best used to convert non EFI to EFI

I do not have it on a car yet, still looking for a project bike to run it on.

https://speeduino.com/wiki/index.php/Speeduino

 

 

[Mad Ax 9292]

@Ray_ve that's really helpful, thanks!

 

So - quick update - Arduino arrived on Weds and I got right into hacking some code onto it.  First impression was great - it connected to the laptop without any driver requirement, the IDE installed with no hassle, I could send code to the Arduino and watch data going in and out on the serial monitor.  Awesome.

I loaded up the code I'd written during the day, I had some issues with understanding the difference between converting an incoming serial character and converting the ASCII value of said character, but after I'd got my head around that and copied from some working code samples rather than trying to be clever and doing it myself, it all started working.  I'd actually written a rudimentary speed controller.  (OK, so I was sending speed data from the PC over serial rather than from a receiver - I'll get to that later - but the principle was proved).

However, there is one drawback with the L298n.  It saps around 2v from the input voltage operating the gates.  That means the motor only got around 7v from a freshly charged NiMH.  Bad news for operating a silvercan.  There are two solutions: 1) use a higher-voltage battery, 2) find a different motor driver.  The L298n was £4.99 so I haven't wasted a lot of money, but a more efficient driver might be more expensive.  I need to look into that.  Using a bigger battery might be difficult in an already-cramped chassis.  My next project will use a King Hauler day-cab conversion, so there's no sleeper to hide the electrics in - everything will have to fit under the hood.  I want to make an interior too, so it'll need to be uber-compact.  I can probably use a 3S LiPo softie in the stock battery position but I'll have to fit (or make) a LiPo alarm or cutoff.  I need to look into that.

I did experiment with driving a TEU-101 using the Arduino.  Actually I used the exact same code as I used to drive the L298n, except I didn't have to send the signals to determine motor direction (there are 2 pins on the L298n that need to be high or low to determine motor direction) and I had to alter the PWM value to fit within the accepted range.  It took a bit of trial and error but eventually I was able to send data to reliably spin the motor at various speeds.

So the next trick is to start designing Phase 1 of my project and start cutting code.  I'll also need to think about any additional hardware.  The NIB rig is all boxed and ready for building, so it's probably a good time to clear off the workbench and get started on a new project...

[WillyChang 1814]

Raspberry Pi is a different beast to an Arduino... Pi is more of a headless barebones computer, Arduino is more of a programmable chip.

Arduino is plenty for controlling lights & sound.

If you want to reinvent a selfdriving car with camera image capture/recognition etc etc Pi would have more computing power. (There's a UK book for Pi projects... its cover pic is of a Pi-equipped TL01B)

[Ray_ve 1043]

A L298 can effectively handle about 2 amps of current. 

I would use it up to a 380 size motor,  but not for a 540 size Silvercan motor, its current draw is too high.

You would need a stronger H bridge chip, custom build H bridge made from MOSFETs, or as you do it is better to control an ESC which has all of that already inside.

[Mad Ax 9292]

Yes, the L298n was really purchased as proof of concept and I'm not upset at losing that amount of cash on it.  However I doubt I'll use a basic ESC going forwards unless I can get one that is completely devoid of its own processing genius.  The TEU-101, for instance, and its clever FWD/BRK/REV lockout that makes perfect sense on paper but makes it really hard to use in practice.  I'd much rather use a better H bridge if it saves having to build something myself, I did find something that has brake functionality too although I'm not exactly sure how the brake worked and if I would be able to control it, or if it was just a resistor across the motor terminals.  Also couldn't find a spec sheet that listed the voltage drop across the bridge.

Actually that's something I'm going to struggle with more than any other - not knowing what products are available to do what I'm trying to and what potential drawbacks they might have.  But I guess as soon as I choose a product I can start coding for it before it's been delivered.

I may not make much progress until after Christmas now - the December budget has been completely blown already and I won't have that much studio time over the holidays.  (I find it quite bizarre that I have more time to myself during a normal working week than I do during a holiday period...)

[Mad Ax 9292]

New thread now here