Leafbot

[hmbright]

This is version 0.1 of a little robot based on a Dagu Wild Thumper with a Raspberry Pi, two Pololu G2 motor controllers and an RC battery. Motors have been replaced with 99:1 gear ratio for better slow control. (the wires look like they touch the hot chips in the photos but they are routed away from hot chips during assembly).

There is an First Person View interface through the Raspberry Pi Camera using a python web server on the Pi running over Wifi with video through ffmpeg and JSmpeg. The Robot can be controlled by an Xbox controller by plugging into the PC USB jack.

The arm is a Lynxmotion system with an Acrobotics gripper. The Pi controls the arm servos and G2 motor controllers using the pigpio project which allows Pulse Width Modulation on the Pi GPIO pins.

It uses lots and lots of custom made wiring using Pololu wiring and connection / crimping supplies. The servos are powered by a Pololu 6v regulator and the Pi by an Adafruit UBEC regulator + usb connector parts. This goes through a simple custom circuit board with a lot of soldering and paper-clip circuits on the back. (I know it looks like the wires touch the hot chips but they don’t when assembled). The electronics are all attached to the underside of the Thumper top, and the default Dagu wiring has been rebuilt with XT60 connectors that plug into the topside for assembly.

Future plans:

• Upgrade Pi regulator to Pololu 5v 5a regulator
• Connect Pi to Pololu G2 controllers using data instead of RC
• Upgrade wifi range with a usb dongle + antenna,
• Add multi-watt LED with LED driver
• Add Pololu current detector, to estimate battery charge
• Improve html interface
• Clean up wiring

Thanks

[BrandonM]

That looks awesome! Great job. Thank you for sharing. Your future plans sound like neat improvements as well; I’m excited to see more updates!

Brandon

[hmbright]

version 0.2

The main prototype board is completely rewired with a bunch of Pololu wiring, connectors, pins, crimp tools, etc. Raspberry Pi 5v power now comes from Pololu 5v 5a regulator, wired directly to GPIO pins, because powering via the MicroUSB on the Pi always resulted in low voltage warnings in dmesg and cpu throttling. The tricky bit here is not to flip polarity and fry the Pi when experimenting. Max current draw is when video is streaming and everything else is on

Robot Arm servo power is still from a Pololu 6v regulator - but i have also wired the Enable pin to the Raspberry Pi, and pulled it down with a 10k resistor. This allows a low power sleep-mode.

I added a Meanwell 1 amp LED driver, with a LED mounted on the front of the bot, with a piece of aluminum scrap as a heat sink. The Pi is connected to the LED driver PWM brightness pin, with a 10k pullup(pulldown?) to make sure it’s off when the Pi is off. Brightness can be controlled from the robot control web page.

There is also a usb extender port for plugging in a Wifi Dongle antenna for better range outdoors.

Software: A separate linux Process was created to stop all main wheel gearmotors within 0.5 seconds if there are no controller commands coming in from the network. The old bot would get stuck moving when connection was lost, repeating to itself the “go forward” command forever without stopping. This Process also will put the robot to a lower power sleep mode if a minute or two go by with no input.

The controller webpage can remap the buttons and axes for any usb-pluggable gamepad controller, and the robot will remember the mapping. Tested on PS2-style and Xbox-style. DarkMode/LightMode added, and some more statistics from the robot like Wifi signal strength, low voltage warnings, etc.

---

I have broken several of the 25D wheel motors gearboxes when the robot fell, about 2-3 feet. I combined broken parts and spares to fix the broken gearbox. I also broke all of the robot arm Servos and had to replace them with sturdier versions.

Several different batteries will work, although the wheel gearmotors ideally want 6v. I am using mostly NiMH radio control car batteries but have also built some custom LifePo4 battery packs. (I do not think hobby Lithium Ion are safe enough for this). The whole thing stalls at about 10 amps total with about 7 volts so I’ve been using batteries rated for at least that discharge rate.

I accidentally shorted the battery through the mainboard when one of my poorly built Deans connector (the t-connector) had a tiny little bit of the wire poke out and touch the frame of the robot just the wrong way. I had a PCB controller on the battery I was using that is supposed to stop short circuits - it did, but it fried itself in the process. One of the header pins on the main board also acted like a fuse and melted. The Pololu regulators, controllers, and Raspberry Pi survived all this somehow.

Future plans.

Use point to point wifi, not a router. Boost range.
See if there are non-marking tires available.
Infrared camera.
Backup camera.
Ultra low power sleep mode, wakeup over bluetooth.
Smarter brain process, to stop it from going over cliffs or tilting over.
Image classification.
“PC-web-less” mode to allow direct control from a wireless gamepad.
Keep trying to figure out Pololu G2 Motor Controller serial commands with Pi (tried this but failed). To cut down on the amount of wiring needed.
Maybe use a Pololu Servo control board, again to cut down on the amount of wiring. (and maybe stop some of the servo hum…)

Thanks

[hmbright]

point to point wifi - apparently there are a few drones (called ‘wifi drones’ like the Trello) that use ad-hoc “point to point” wifi. the computer and/or phone connects directly to the robot by disconnecting from normal wifi and reconnecting to the robot using “ad hoc” wifi mode. so the wifi is just between the computer and the robot, thats it. no router needed. Adhoc wifi seems to be a bit janky - it seems to me like its something that very few people use so maybe it just doesn’t get tested / fixed as much as normal wifi. For example the MacOS wifi-scanner for example seems to not correctly show the name of the robot in the wifi list very well. It’s a bit of a janky process to disconnect from wifi, and connect ad-hoc to the robot, then after finishing working with the robot, reconnect to wifi. The robot also has to deal with the fact it cannot connect to normal wifi when it is in ad-hoc mode - it basically has to reboot. The settings seem to also be super janky as you can use ad-hoc on a dongle only if onboard wifi is disabled in the boot system. So to switch between ad-hoc and normal wifi you need to basically reboot. When you actually get everything into ad-hoc mode it works but it just doesn’t seem very smooth or elegant as an overall experience.

bluetooth gamepad - the range is very limited but it works. literally about 20-30 feet. This is using the Raspberry Pi native built-in bluetooth. This is a Nintendo Switch-compatible bluetooth gamepad from the PDP company. One interesting bit is that “evdev-joystick” doesn’t really help - it only allows reading of “Events”, and if you hold the ‘go forward’ stick in the forward position, one event will be triggered, but after that initial event, no other event will be pumped through the evdev subsystem. So how does it know the difference between a go-forward command and a connection being lost? To deal with this issue, the robot just doesn’t use evdev-joystick. It reads bluetooth data directly from HCI by reading hcidump. This data is acually continuously streaming from the gamepad so it gives very low latency feedback.

[jlo]

RE point to point WIFI: my experience has been a little different, maybe I’m doing it differently from you. Instead of looking for my router’s access point, I have my robot look for my phone’s access point when the phone is in hotspot mode. Once it connects I can establish a TCP connection to the phone and proceed as usual. The phone has a very limited DHCP service so the “dynamic” address it assigns is the same every time (and the phone’s address is static as well). As far as I can tell, there’s no difference in the WiFi connection from the robot’s perspective, so theoretically it could go out to the internet through the mobile data connection provided by my phone. Restoring the phone is simply a matter of turning off the hotspot, and the robot is always free to try to connect to any other WiFi access point it can see. I also tried the reverse where the robot advertises an access point and the phone connects to it, but I settled on the other way for reasons I don’t remember. And the range I’m getting seems to be a little better than the old router I was using, so I’m happy not to have to have another device to set up. Is what I’m describing less janky than what you’ve experienced?

[hmbright]

Hi jlo, thanks for that info… I have tried using a phone in hotspot mode…and I agree it is much easier to configure than ad-hoc. The robot has the phone configured as just another Wifi point, and I can even use “http://leafbot.local” from a Mac/Linux/Windows machine to connect. It works very well for medium range access. But I would like more range than my phone is able to deliver in wifi hotspot mode. I have an LG K40 i think and its maybe 50 feet before the video kind of becomes slow.

What router did you try? I was hoping maybe to try one of those fancy ones with big antenna poking out everywhere.

One thing i haven’t tried is plugging a Wifi dongle into a phone and then putting the phone in hotspot mode. Not sure if Android is capable of doing that.

Thanks

[jlo]

The router I used with the robot the most is so bad it’s not worth mentioning–it was a spare I had in the closet. I also tried a TPLINK AC1750 and that works really well and is cheap, but that’s my house router; I was considering getting another one before I discovered the hotspot trick. I get similar range as you with my phone hotspot, which is plenty for me for now so I stopped looking for other solutions. But for sure, if I had to use the robot in a theater (which is what I originally developed it for) I would fall back to using a router, maybe even a mesh system.

[Keonte45]

Wow!! Thank you for sharing your project and progress.