When the remote for your son’s RC car goes missing, what are you going to do? Throw away a perfectly good robot chassis? No, we wouldn’t either. And these days, with WiFi-enabled microcontroller boards so readily available, it’s almost easier to network the thing than it would be to re-establish radio control. So that’s just what [Stian Søreng] did.
Naturally, there’s an ESP8266 board at the heart of this hack, a WeMos D1 to be specific. [Stian] had played with cheap remote-controlled cars enough to be already familiar with the pinout of the RC IC, so he could simply hook up some GPIOs from the WeMos board to the pins and the brain transplant was complete.
On the software side, he implemented control over TCP by sending the characters “F”, “B”, “L”, or “R” to send the car forward, back, left, or right. Lowercase versions of the same letters turns that function off. He then wrote some client software in Qt that sends the right letters. He says that response time is around 150-250 ms, but that it works for his driving style — crashing. (We’d work on that.)
Anyway, it’s a fun and fairly quick project, and it re-uses something that was destined for the junk heap anyway, so it’s a strict win. The next steps are fairly open. With computer control of the car, he could do anything. What would you do next?
Thanks [Eyewind] for the tip!
is it me or is 150 – 250 ms a bit, would udp be better ?
I was thinking the same. That and maybe try setting MTU to as small as possible.
Reducing the MTU will not have any effect. It is the maximum packet size you can send without needing to fragement it. A one byte packet (F, B, L, R) will not be fragmented, no matter the MTU. Fragmentation adds further latency because you send multiple fragments for multiple for one original packet.
It’s been years since I’ve done any low level socket IO development, so I’ll accept that I could be talking complete rot ;-) but my thinking was that if you set the packet size to be 1 byte plus header size, then each command/packet would have to be sent immediately instead of possibly waiting for more bytes to fill the packet … ?
That’s Nagle’s Algorithm, which you can turn off in software. Or switch to UDP instead.
UDP would definitely be the way to go here.
Websocket or MQTT http://mqtt.org/ would be ideal.
“Naturally, there’s an ESP8266 board at the heart of this hack”
So, is the arduino dead?
no just the esp8266 gives integrated wifi nd processor in one compact package – Use the most appropriate right tool for the job
So before esp8266 the most appropriate tool for any job was the arduino? :)
The big problem here is the “toy speed” X “wifi latency and noise”, I made similar project using a war tank chassis and ip camera (or two android phones over wifi).
I Added a condition to stop the motors if no command is received in 500ms timeout (sometimes we have big delays or concurrency), otherwise the toy can fall down the stairs. ^^
If speed is high, the toy should not fall but fly ( and you may want to add a parachute lol)
I hope write next 2 intructables as continuation of this http://www.instructables.com/id/RC-toy-Arduino-Controlled-by-2-wires-signal-and-gr/ soon
“otherwise the toy can fall down the stairs.”
That’s not a bug, it’s a feature!
B^)
lol
so will be nice add a quadcopter on top =P
I just happen to have a dead R/C car I saved figuring I could make something cool out of it.
The big problem here is the “toy speed” X “wifi latency and noise”, I made similar project using a war tank chassis and ip camera (or two android phones over wifi).
I Added a condition to stop the motors if no command is received in 500ms timeout (sometimes we have big delays or concurrency), otherwise the toy can fall down the stairs. ^^
If speed is high, the toy should not fall but fly ( and you may want to add a parachute lol)
I hope write next 2 intructables as continuation of this “http://www.instructables.com/id/RC-toy-Arduino-Controlled-by-2-wires-signal-and-gr/” soon
Bluetooth might be a better solution than wifi here, unless you’ve got something laying around of course.
The big problem here is the “toy speed” X “wifi latency and noise”, I made similar project using a war tank chassis and ip camera (or two android phones over wifi).
I Added a condition to stop the motors if no command is received in 500ms timeout (sometimes we have big delays or concurrency), otherwise the toy can fall down the stairs. ^^
If speed is high, the toy should not fall but fly ( and you may want to add a parachute lol)
I hope write next 2 intructables as continuation of this instructables id “RC-toy-Arduino-Controlled-by-2-wires-signal-and-gr” soon
I thought was any problem in my browser or massage… I can’t pass in sanity check in this time I think…
Moderator, can you delete the duplicated posts, please… :~~
Marco and djneo are right, wifi might be a bit slow for a hobby chassis with a hot motor in it. repurposing a 10mph childrens toy, though… Absolutely a good idea.
I stuffed an arduino Uno and seeed motor shield into a tamiya RC tank and turned it into a little obstacle avoider robot using simple photodetectors and LEDs… would’ve been very cool to put the esp8266 and a camera in that.
I like ESP8266 standalone for small applications. It is the best (easy) choice that I found. I’m replacing some RF24l01 in some projects =)
I preserve RF24l01 only in low power applications
Perhaps using websockets could speed this thing up :)
I honestly can’t say how many RC cars we’ve thrown away because of lost remotes. It’s good to see that there’s a solution for this, I’ll definitely have to give this a try with my nephews. Thanks for sharing!