I have a been an embedded engineer for basically all of the 2000s and have collected a very wide array of hardware over the years.  I figured I would put up various bundles  of development kits to raise money for the new hardware.  Some of these devices might be available for cheaper just remember that you are supporting a fellow tinker/hacker/maker with their project.

First come first service, email me(king.seth@gmail.com) with the interested package in the title.  Give me shipping information and method(cheap vs fast) and payment method (Google Pay would be the best.)

Here is a list of the options and targeted prices(shipping is extra) with pictures below:

Particle Spark package: 80$
Arduino package: 120$
ST package: 80$
Beagle package: 400$
Atmel Xplained package: 70$
Atmel Dragon/Misc Package: 65$
Atmel Sam 3x-ek Ice Package: 300$
Omap-L138 package: 300$
Renesas package: 50$
Gumstix package: 50$

Over the last couple of months have written a C++17 library for communication data to the the motor controllers.  I have implemented all of this on the Nvidia Jetson TX1.  I have also upgrade all the scripts to C++ and ROS2 and with ROS2 - a PS4 controller.

So I have gotten all of this stuff working with the Jetson plugged into a power supply and I wired up an adapter for a small battery pack.  There was an issue with the Jetson recognizing the battery pack but that was fixed by adding a capacitor to the barrel jack on the Jetson.

So it was time to take it out in the real world.  There was a circus of errors just to get it driving around.  The door to my basement to too small so when I picked up the rover, the cap connection broke and I had to do some redneck soldering.  Snapped one of the legs, this was one of the old joints that I did originally back in the summer of 2017 with a borrowed welder.  I had to quickly grind down the joint and weld it up.

There is a bit more tuning with speed of the motors and the wheels might need to be tightened up a bit but I call this a major break through.

Here is an example of an application that I came up this week:

I have a bused wheel barrow that I used over and over to move mulch around the yard.  This simple application would be a wheel barrow attached to the top with some sort of dump mechanism.  The software would allow the user to configure a series of waypoints that would be dump x loads at this point on the map.  The rover would start at the mulch pile, the user would fill the wheel barrow and hit a button.  The rover would drive to the waypoints and dump the load and then return to the mulch pile.

Technical Update

I got the new motor controller in and soldered on the battery connector and the bullet connectors for the motor.  I am able to get the command line test program to control both motors.

I battle the ROS2 launch file for a couple of days but then just lauched the nodes manually.  I got all 4 processes working:  PS4 driver, Joy stick Node, Teleop Node and Vesc node.  I was able to get the PS4 controller to control the two wheels. All of the motor control interactions are C++ instead of python so the control seems a bit more dynamic.

The last step this week was to work on the right hub motor mounting.  This wheel also has a problem that the tire does not hold air so I am going to try to take the tire off and clean the rim off.  

Tested out the new debug commands this week and they work really well.  I was able to figured out range of RPM the motor supports.  I can set RPM and the controller will drive the motor and control based on feedback.  Unfortunately one of the controller was not responding to any commands and when I tried to configure it, one of the tests toasted a chip on the board.  I ordered another one but I have to wait til it gets here then solder on the battery connector and the bullet connectors.

If you are interested in Open Rover and want to help or give some feedback please sign up in the form below.

Overview:

Currently, outdoor unmanned ground vehicles (UGVs) are expensive (average of 20K$) academic pursuits that are not readily available at a high volume.  Open Rover's goal is to create a lower cost, standardized outdoor robotics ground vehicle with 4 and 6 wheel options based on intended application. These rovers will be able to map a given area and localize themselves within this map.  Easy-to-use tools and APIs will allow everyone to create simple-to-complex robotic applications.   We will be targeting organic agricultrual applications in the beginning.

Technical Update:

The latest findings of the Open Rover project have proved that low cost scooter motors can move the robot at the pace and level of control that we think is neccesary.  However, most of the code of python and ROS on these motors caused lags in control.  To address this issue, we created a custom C++17 library to communicate with the motor controllers.  We are currently in the process of integrating with ROS2 all based on C++.  After we verify basic mobility with a PS4 controller, we will be transitioning to working on the computer vision and mapping abilities.  Acquiring a stereo camera to aid map generation will be the top hardware prority.

So the pressure was on this spring to get the rover driving around at least via the wiimote because the deadline for Georgia Tech's Create X summer program was looming.

In the fall I got one of the VESC units controlling a single motor with the wiimote. So this spring I was working on getting both motors to work together so that I could drive the rover around the yard.

Over the course of a couple of weeks, I got both motors working with two VESC controlllers and was able to crash the rover multiple times. The last time was so bad that multiple weld joint broke collapsing the whole rover in on itself.

I had to get a grinder and clean up a lot of the bad weld joints that I had originally done back in the summer of 2017 with a coworkers underpower welder. Since then I had acquired my own fluxcore welder which was more appropriate for the task. So I basically had to redo the whole frame and in the process I got some sheet metal from a local metal shop and I created a shallow metal box that sits in the frame. It is a little deeper than the battery packs and there is plenty of room for the laptop/TX1 and cable routing.

So I eventually got the rover bumping around the yard but this was not enough to get me into Georgia Tech's Create X progam so I am back to the slow grind in my basement. See below the application video.

I was able to have a very production conversation with the professor that I did the elective 2 summers ago. We came up with a good plan to polish some of the control mechanism and then steps to add autonomy.

I am currently working on refactoring the serial communication library from a python script to a C++17 library.

My prior method of control the motors was to send a duty cycle to the VESC based on the position of the wiimote. I found out that the VESC has the ability to do some closed loop control when given a set RPM. Now I don't have to do this in the ROS node. This will be a lot more tigher control loop.

I have some C++ test code talking to VESC and now I am investigating creating a ROS 2.0 node. This node will subscribe to the twist msg that the Teleop node sends out based on the wiimote state. Then it will read various motor stats and publish them to ROS system.

Rover Driving

After the failure and destruction of my third motor controller, I decided to go in another direction. I purchased a VESC(open source BLDC controller) off of amazon and was able to get the hub motor spinning both directions.

It took me a while to figure out how to communicate to the VESC but I was able to create a python program that could set the speed of the wheel and monitor the speed and other stats.

The next phase was to connect the wii-mote code that I wrote last summer with this new python library. I was able to control one of the wheels with the wii-mote so this is a huge step on the way to getting the rover mobile.(See video below)
I have purchased the second controller and just need to wire up the second wheel and update the code to control both wheels at the same time. I might hook up a kind of redneck e-stop.(extension cord to a batteryless laptop) Because that last thing I need is the rover to drive away and flipover destroying all the electonics. This is the last step in the PoC hardware phase once this is verified then I can move on to working on the SLAM and automated software phase.

Wiimote controlling hub motor

I didn't have any time to work on open rover during Fall of 2017 as I was taking 2 classes. In the Spring, I was taking the dredded algorihms class as my last class to finish up my degree. But during the Christmas break I was able to update the BLDC shield schematic. I filpped the fets around so that a heat sink could be attached and that they would not be as close to the wires coming out of the board. I upgraded to a very expensive switcher and to protect it a schottky and TVS because my theory is that the back emf from the motor was damaging the controller. I was able to get the pcbs from china but then the Spring semester hit.

After graduating I upgraded to an Nucleo F303RE with the arduino headers because the arduino couldn't process the serial commands and manage the IO without glitching. So I have implemented and tested out the serial protocol.Now I am porting all of the IO which was a mess to the mbed-os classes. Got the mbed os to compile with C++17 love the std::clamp function.

I ordered some higher current connectors for the motors because I was just using horrible AC connectors from Home Depot and it was a pain to disconnect the controller from the batteries. So I have rewired the motors, the batteries are a bit more awkward but I can used a power supply for the intial testing. I want to build a small pcb with the new connector that will have the three bi-color leds so that I can test the boards at lower current and verify the commutation states.

I got a free month at the local makerspace so I am able to work on it there. I might clean up the welding and redo the wheel mounts because the hub motors kind of rub the legs if too much wait is put on the platform. I did get a flux-core welder for christmas :)

Hope to get one of the motors spinning in the next week or so. The new code and schematics are in the repo.

The biggest breakthrough occurred in getting the hub motors spinning with the custom controller. One of the most important lessons learned involved a fundamental electrical engineering tenant: power dissipation of a linear voltage regulator versus switching power supply. The initial design used a linear voltage regulator that was consistently being damaged. The power that needed to be dissipated was too large, and the high temperature would then damage the regulator. This caused additional problems because the higher battery voltage would be applied to the motor drivers and damage them as well. Once this setup was replaced with a switching power supply, the controller was significantly more reliable. There were a lot of unknowns that were exposed throughout the duration of this project: sensors needed for SLAM, the importance of suspensions, basic ROS node architectures, static stability, and practical construction techniques.

The final goal of this project was to use to a Wiimote to drive the Rover, thereby testing the movement model and suspension. This was unable to be accomplished because the motor controllers were not robust enough for extended use. Both controllers were damaged when attempting to test the change of direction command. The time and cost to repair the controllers would extend the project outside the allotted time. There are multiple improvements that can be implemented in order improve the construction and reliability of the motor controllers. Continuing to reverse engineer the low-cost Alilbaba controllers will hopefully result in more gained knowledge that can be applied to future versions. The quality of construction of the current Rover could be improved as well. The frame would need to be disassembled and welded with higher quality tooling.

Once the controllers are stable, the plan will be to implement a SLAM algorithm with one or two cameras. The laptop will be replaced with the Nvidia TX1. This will allow Open Rover to map an area that has been digitally fenced off. A simple smartphone app could be used to create the digital boundaries. Providing simple straightforward navigation APIs are a foundational feature of Open Rover. Additional hub motors will need to be acquired as well so that prototypes of the four wheel and six wheel Rovers can be constructed.

Videos:
Open Rover Construction and Modelling videos

The modeling was completed based on 50mm square tubing. The mounting bracket for the hub motors was 40mm, so 38mm square tubing was used in the construction of the Rover. Only two hub motors were available for the proof of concept, so two smaller, non-powered wheels were utilized on the front. To protect the motor from overcurrent damage a 10 amp fuse and switch were wired inline with each battery and controller pair. Robot Operation System(ROS)¹ is one of the industry standard for robotic software subsystems. It will be used to collect sensor data, calculate path planning and communicate the appropriate velocities to the left and right motor controllers. Simultaneous localization and mapping(SLAM)² will be used to map out the target environments and the Nvidia TX1 has very efficient computer vision capabilities that will aid in this task. These functionalities are not within the scope of the class so a Wiimote(bluetooth video game controller) will be used to simulate directives to the wheel subsystems. The Wiimote will communicate via bluetooth to a laptop. A ROS node will convert the analog joystick values into an appropriate velocity and direction which will be sent to each wheel via a serial communication bus. Additionally the ROS node will request current, velocity, gains and PWM settings. All of the wheel data will be bundled and sent to the system for instrumentation and data capture for future analysis.

FootNotes:

1. http://www.ros.org/
2. https://en.wikipedia.org/wiki/Simultaneous_localization_and_mapping

The second main goal of this Special Problems course was to model the various versions of the Open Rover. There are three version of Open Rover: 4 wheels(two hub motors, two passive motors), 4 wheels all hub motors, and 6 wheels all powered. The main requirement difference between the 4 wheeled and 6 wheeled rover was to give an additional option for applications that would require higher torques e.g. hauling a large load or climbing more difficult terrain. The 4 wheeled model with only two hub motors is the proof of concept that will be constructed. Only two hub motors are available for the PoC. Coming into this project, there was no true guiding principle that would dictate the Rover’s dimensions. The general idea was to have sizing similar to a push mower. Multiple metrics were extracted from the PhD thesis of Thomas THÜER. Theta of static stability is the maximum angle in which the stability margin becomes zero. The x(longitudinal) and y(lateral) variables are independent of each other and stability is calculated based on the geometry of the center of gravity compared to the points where the wheels contact the ground. The formula is as follows:
ThetaSS = atan(Xrear/z)

Longitudinal and lateral stability figured taken from Thomas THÜER PhD thesis¹

Xrear can be exchanged for Yleft/right, and both are half of the width and length respectively because the vehicle has a symmetrical center of gravity on both the x and y axis. Therefore, the wider and longer the Rover is at a specific height, the more stable it is. There is an arbitrary factor of, from a practical standpoint, how large the Rover be.

A three dimensional graph was created to give a better view of how the Theta of static stability changes with varying dimensions.

The first model had a length of 1 meter and a width of 0.5 meters. To maximize the Rover’s stability in both the x and y, 0.75 meters was selected. Cost and practicality are limiting factors in making the rover any larger. For the target applications, the general size of a yard lawn mow used as a guiding principle. This improved the combined static stability as the table below shows:

The initial design of the 4 wheeled Rover was going to be a static frame. By adding a simple pivot point to the front pair of wheels, the stability of the Rover is improved by allowing all of the wheels to maintain contact with the ground.

A six wheel model was designed for applications that would require higher torque. For the sake of reusability and consistency, the back suspension was replicated on each side of the main chassis for two independent boogie suspensions. This continues the dynamic of allowing all wheels to be in contact with the ground as an obstacle is traversed. The main frame expanded to 1.0 meters in length to allow enough clearance between the rear wheels and the middle wheels in the boogie. The ExoMars rover was inspiration for this suspension configuration.²

Footnotes:

1. Mobility evaluation of wheeled all-terrain robots - Thomas THÜER
2. https://en.wikipedia.org/wiki/ExoMars_(rover)

Three development paths were available in the proposal. All three paths were tested, and the results were conclusive as to which option produced the optimal results.

Option one: Use off-the-shelf evaluation boards
Two Monolithic Power Systems EV6532 evaluations boards were acquired. The boards require three control signals as well as power and motor and sensor connections. The three control signals, Speed (PWM), Direction (TTL) and Brake (TTL), were provided by an ST embedded controller. A 36V battery serves as the power source for the motor. Initially, a simple circuit was created to power the Hall Effect sensors in the motor and to pull up the voltage to the embedded controller voltage. An imbalance in the ground planes between the embedded controller and the evaluation boards was discovered as well as a significant noise issue that was causing the motor to turn off upon starting. Additional isolation and filter circuits were created, but the noise continued to hinder startup of the motor. At this point in development, option one was shelved until all of the other options were tested.

EV6532 with ST microcontroller and breadboard for pullup resistors.

Option two: Use off-the-shelf scooter motor controllers

Three scooter motor controllers were purchased off of Alibaba. These controllers were low cost, and documentation was minimal. Only two controllers were needed, but a third controller was purchased in order to disassemble and reverse engineer. The controller came with 9 connectors. Battery, hall, and motor connections were similar to the connection on the motor. The vendor would not provide any additional documentation about the controllers so this path was abandoned. Despite not being able to use the controllers, knowledge was gained from disassembling one of them. The layout of the Field Effect Transistors(FET) was used in option three to allow for higher current usage.

Underside of Alibaba controller. FET layout was used in the custom shield design.

Option three: Design custom controller based on open hardware designs (Arduino)

A BLDC shield for the Arduino was designed based on criteria retrieved from reverse engineering the low cost Chinese controllers. The boards were assembled and tested. A design flaw was found pertaining to the voltage regulation of the FET driver, and a new part was used to dissipate the appropriate amount of heat (power). Once this issue was addressed, the hub motors were successfully started in both forward and reverse. A command protocol was implemented to allow the setting and retrieving of current, pwm, velocity, gains, and direction. A PI velocity control algorithm was implemented. An additional improvement for the future will be current regulated speed control or direct torque control.¹² There a multiple hardware improvements that need to implemented to make the controller more robust. These include reorienting the Field Effect Transistors to allow for a passive heat sink. Replacing the voltage regulator with a voltage switcher. And better strain support or mounting for the cabling.

Custom shield for Arduino

Footnotes:

1. http://ieeexplore.ieee.org/abstract/document/4270633/
2. http://www.st.com/content/ccc/resource/technical/document/application_note/90/b9/df/c9/0c/cc/4c/4d/CD00075973.pdf/files/CD00075973.pdf/jcr:content/translations/en.CD00075973.pdf

The overriding object of Open Rover is to create a low cost outdoor robotics platform. It will lower the barrier of entry for school projects, professional engineering teams or even the lone hacker in the basement. Open Rover will free teams to focus on end applications instead of hardware and basic navigation issues.

Two main goals presented for this Special Problems class:

• Develop a low cost motor controller that will allow the usage of off-the-shelf hub motors.
• Create models of the different versions of Open Rover and test them in a virtual environment. A stretch goal was to build a proof of concept rover and compare this to the models.

Open Rover has been a long frustrating road. With two young boys and grad school(Georgia Tech's OMSCS), working on a side project was non-existent. I am 70% through the program over two and half years and 4 of the robotics classes that I was looking forward to taking have not been added to the online circulum as I had desired. I petitioned 4-5 professors about when these classes would be added to the online degree and basically got radio silence. CS 8903 Special Problems is an elective but only 3 hours can be applied to any degree. My initial plan was too attempt to work out some of the hardware problems(of Open Rover) in a Special Problems class over the summer and then attempt to be the first OMSCS student to do a Master's Thesis project if the summer class bared any fruit. I was able to get a great advisor(Cedric Pradalier of Georgia Tech Lorraine) for the summer class and Open Rover was reborn as CS 8903 Special Problems class.