Sawppy Roving With Wired Handheld Controller

I now have a basic Arduino sketch for driving Sawppy using a joystick, I’ve built a handheld controller using an Arduino Nano and a joystick, and an input jack for interfacing with Sawppy. It’s time to put it all together for a system integration test.

Good news: Sawppy is rolling with the new wired controller! Now if there’s too much electromagnetic interference with Sawppy’s standard WiFi control system, we have a backup wired control option. This was the most important upgrade to get in place before attending Maker Faire Bay Area. As the flagship event, I expect plenty of wireless technology in close proximity at San Mateo and wanted this wired backup as an available option.

This successful test says we’re in good shape electrically and mechanically, at least in terms of working as expected. However, a part of “working as expected” also included very twitchy movement due to super sensitive joystick module used. There is very little range of physical joystick movement that maps to entire range of electrical values. In practice this means it is very difficult to drive Sawppy gently when using this controller.

At the very minimum, it doesn’t look very good for Sawppy’s to be seen as jittery and twitchy. Sharp motions also place stresses on Sawppy’s mechanical structure. I’m not worried about suspension parts breakage, but I am worried about the servos. Steering servo are under a lot of stress and couplers may break. And it’s all too easy to command a max-throttle drag racing start, whose sudden surge of current flow may blow the fuse.

I had wanted to keep the Arduino sketch simple, which meant it directly mapped joystick movement to Sawppy motion. But it looks like translating the sensitive joystick’s motion directly to overeager Sawppy is not a good way to go. I need to add more code to smooth out movement for the sake of Sawppy’s health.

Sawppy Wired Controller Enclosure

I now have an assembly of circuit boards that has all the electronics I needed to create a wired controller for Sawppy the Rover. Now I need an enclosure to make it easy to hold, protecting both my skin against punctures by header pins and also protecting the soldered wires from damage.

The first task is to measure dimensions and iterate through design of how I would hold the assembly using 3D printed plastic. It evolved into two separate pieces that mate up with left and right sides of my prototype circuit board.

The next step is to design and print two small parts to hold on to the wire. The idea is to have it take some stress so tugs on the wire do not rip my 4-pin JST-XH connector from my circuit board. And finally, an exterior shell to wrap all of the components.

Sawppy handheld controller unassembled

The exterior shell was an opportunity to play with creating smooth comfortable hand-conforming organic shapes. Designing this in Onshape was a bit of an square peg in round hole situation: standard engineering CAD is tailored for precision and accuracy, not designing organic shapes. That’s the domain of 3D sculpting tools, but I made do with what I had available in Onshape.

Given a bit more time I could probably incorporate all the design lessons into a single 3D printed piece instead of five separate pieces, but time is short and this will suffice for Maker Faire Bay Area 2019.

Now that I have one end of my wired serial communication cable, it’s time to look at the other end.

Sawppy handheld controller assembled

Arduino Nano Forms Core Of Sawppy Wired Controller

At this point in the project, I have an Arduino sketch that reads an analog joystick’s position and calculates speed and position for Sawppy’s ten serial bus servos to execute that command. Now I turn my attention back to the hardware, which up until this point is a collection of parts connected by jumper wires. Good for experimental prototyping, not good for actually using in the field.

The biggest switch is from using an Arduino Uno clone to an Arduino Nano clone. The latter is far smaller and would allow me to package everything inside a single hand-held assembly. Both Arduino are based on the same ATmega328 chip and offers all the input and output I need for this project. Typically, beginners like to start with an Uno because of its selection of compatible Arduino Shields, but that is not a concern here.

This specific Arduino Nano will be mounted on a prototype perforated and plated circuit board. It is placed on one end of the board in order to keep its USB port accessible. Two other components were soldered to the same prototype board: a 4-pin JST-XH connector for power and serial communications, and an analog joystick module.

My mess of jumper wires were then replaced by short segments of wire that are soldered in place for greater reliability. This is a relatively simple project so there aren’t very many wire connections, and they all easily fit on the back.

Arduino nano with joystick on PCB back

In theory the Arduino sketch can be seamlessly switched over to this board. In practice I saw bootloader errors when I plugged in this board. It turns out, for this particular clone, I needed to select the “Tools” / “Processor” / “ATmega328P (Old Bootloader)” option in Arduino IDE. As a beginner I’m not completely sure what this meant, but I noticed sketch upload speed is significantly slower relative to the Uno. My source code was unchanged and it all still worked. A few test drive sessions verified this little hand held assembly could drive Sawppy as designed.

Next step: an enclosure.

Prototype Arduino Wired Controller For Sawppy

Once I had basic control of LewanSoul LX-16A serial bus servo via analog joystick with an Arduino Uno, it was time to write code to perform trigonometry math necessary to calculate Ackerman steering angle and speed for each of Sawppy’s six wheels. Conceptually this is a port of code I wrote for the SGVHAK Rover project. However, that had the benefit Python, a high level friendly language.

The first concern came from reviewing Arduino Language Reference page. Under Trigonometry section it lists cosine, sine, and tangent functions but I didn’t see their counterparts arccosine, arcsine, and arctangent which I needed. I was never worried that I might have to reimplement my own math library: surely one would exist! They’re too useful and the Arduino ecosystem is too large for them not to.

It turned out I didn’t have to go very far in my search: underneath all the beginner-friendliness the board still runs an ATmega328 chip of the AVR microcontroller product line. And Arduino has not deviated from core language for programming that chip, so I could pull in the standard AVR <math.h> library to gain acos(), asin() and atan() functions.

I only had to duplicate the math for an Arduino counterpart, I didn’t try to replicate all the features of my Python code since some of them relied on the nature of Python for their flexibility. Still, even with the simplifications (or possibly because of them?) the code was different enough for some bugs to slip in. I ended up retracing through my steps using pen and paper to debug a few problems.

Once debugged, I had a crude wired controller for Sawppy. An analog joystick connected to my Arduino Uno with jumper wires provides user input. My freshly written code translates the joystick position to four corner steering angles and six wheel velocities, and sends out commands to all ten LewanSoul serial bus servos using Arduino’s UART TX pin connected to LewanSoul BusLinker via another pair of jumper wires.

Next task: make this Arduino wired controller more compact and more reliable with soldered wire connections to replace these jumper wires.

(Code for this project is publicly available in the arduino_sawppy subdirectory of Sawppy Rover’s Github repository.)

Arduino Control Of LewanSoul LX-16A Servo Via Joystick Commands

Once I climbed a few early steps on the Arduino IDE learning curve, I was off and running writing code. Fortunately the underlying code for programming an Arduino is still the C++ I’m familiar with. I picked up where I left off earlier with the analog joystick tutorial, now shuffled off to its own C++ class. I then looked over the sample code released by LewanSoul for controlling LX-16A servos in the form of a single flat Arduino sketch file.

I don’t plan on using most of the functionality of that sketch, but I thought it was easiest to lift the code wholesale rather than putting time into extracting just the parts I wanted to use. The code was written as flat top-level APIs, but it wasn’t difficult to write a small class that exposed a few methods which called into the two API I cared about. One to make a LX-16A move to a specific position, the other to make it rotate continuously.

There were a few rounds of experimentation on how exactly to communicate intent across this API. Using values as directly dictated by LewanSoul would have worked fine for this one case, but I didn’t want to be tied to one specific servo. Like my SGVHAK Rover software project, I wanted this code to be adaptable to multiple motor implementations which meant a more general description of motor action.

I tried percentages for both, ranging from -100% to +100%. For position servo, this would mean -100% is full deflection left, 0 is center, and +100% is full deflection right. And for continuous rotation, -100% is full speed reverse, 0 is stopped, and +100% is full speed forward.

Speed worked well but position did not: different servo will have different ranges of motion, so full deflection would mean different angles for different servos. So that was changed to angle in degrees. In the case of LewanSoul, -120 degree to +120 degree.

This was enough to let me control two servos with an Arduino, based on position of the connected analog joystick. This is sufficient control for my standard “rover wheel on a stick” test case, a good milestone before proceeding onwards.

(Code for this project is publicly available in the arduino_sawppy subdirectory of Sawppy Rover’s Github repository.)

Additional Source Code In Arduino Sketches Are Tabs Not Files

Being an electronics hardware tinkerer, there was no way for me to be ignorant about Arduino, but it never quite seemed to fit what I needed for a project: if I wanted computing power I used a Raspberry Pi, and if I wanted inexpensive low-level microcontroller I used a PIC. But I wanted to make Sawppy friendlier to beginners, and that was my motivation to finally start learning about the Arduino ecosystem.

I understand Arduino’s success is largely credited to how its creators underwent a clean-sheet examination at physical computing with the specific goal of making things easy for beginners to get started. A clean-sheet approach meant that tenure was meaningless. If the creators felt it was not helpful to beginners, it was gone regardless of whether it was a long standing tradition. I read this philosophy repeatedly as I was learning about Arduino, one example among many was this statement from Arduino API design style guide:

Some of these run counter to professional programming practice. We’re aware of that, but it’s what’s made it possible for so many beginners to get started with Arduino easily.

After I felt I had done enough reading to feel like I was properly oriented, I embarked on my project to started writing code for driving Sawppy using an Arduino. It didn’t even take 5 minutes before my well-worn habits ran into a collision with The Arduino Way. I wanted to put joystick tutorial code in its own header (*.h) and source (*.cpp) files instead of putting it in the top level sketch (*.ino) file… and I couldn’t do it.

I selected “File”/”New” in the Arduino IDE, but that created a new Arduino sketch (*.ino). I poked around in various options on the file creation dialog, hoping to see a “create new header file” or similar, but saw nothing dealing with file types. I could see how file types might be confusing to beginners, so it’s Arduino design in practice: avoid file types even if it disorients long time computer programmers.

And I was definitely disoriented. I was so stuck in my old ways I couldn’t figure out what might have replaced it in Arduino IDE. I eventually found my answer by downloading an existing Arduino project with multiple source files and opening it in the IDE: additional source files are tabs! In the Arduino IDE, a “document” is a complete sketch with all its parts. If source code is spread across multiple files on disk, they are represented as tabs when the document was opened.

So in order to create a separate set of files for my joystick code, I need to select “New Tab” and give it the filenames I intended. One tab for joydrive.h and one for joydrive.cpp.

My relationship with Arduino is off to a rocky start, but I’m sure we’ll work it out.

 

Learning How To Write Arduino Libraries and Tutorials

For small software projects like a typical beginner Arduino sketch, we can get away with putting everything in a single *.ino file. This was the way LewanSoul served up their Arduino sample code for controlling LX-16A serial bus servos. But as a software project grows in size, proper organization of software modules become more important.

While I don’t intend to tackle the task of writing a big Arduino sketch, I did want to get an idea of how to write my Arduino code in a way that can be reused in their own installable Arduino library. That’s a powerful part of Arduino’s software ecosystem, but I don’t want to just consume other libraries… I want to get a little practice in so I have the option to write my own libraries later.

I started by reading about the mechanics of creating an Arduino library. As expected of the world of low power microcontrollers, programming is done in C and a library has, at a minimum, a *.h header file and a *.cpp implementation file. This was all in order, an Arduino-specific twist is the IDE integration with keywords.txt. That I didn’t expect. Everything is packed in a ZIP file.

Next I moved on to Arduino’s API design style guide. This is less about the mechanical details, and more about how to structure an Arduino API. This passage caught my attention:

Some of these run counter to professional programming practice. We’re aware of that, but it’s what’s made it possible for so many beginners to get started with Arduino easily.

This might be what caused some of my irritation with Arduino code – design decisions that ran counter to my professional practice, but now I understand there’s a well-meaning reason for it.

From there reading moved to the Arduino style guide for how to structure tutorials that accompany code, then I went back to see the analog joystick tutorial I had referenced earlier, this time as an example of Arduino tutorial style.

Examining LewanSoul Arduino Library

When I first built Sawppy using LewanSoul LX-16A serial bus servos, I was not interested in using their PC software which was tailored to running pre-scripted sequences of motion. At the time I was not using an Arduino, either, so I wrote my own serial communication driver in Python based on LewanSoul’s PDF documenting their serial communication protocol.

This time around, I am using an Arduino and eager to take advantage of already prebuilt software to cut down on development time. In the same Dropbox where I found my LewanSoul Bus Servo Communication Protocol.pdf reference document, there was a file LSC series communication routines of controller.zip. Now that I’ve seen Arduino libraries packaged in a zip file, I looked inside to verify the structure of having *.cpp and *.h source files. It turns out they were packaged inside that zip file as another file LobotServoController.zip. This zip file within a zip file looked like an Arduino library, with LobotServoController.h header file and LobotServoController.cpp source, a keywords.txt for Arduino IDE syntax highlighting, and a few *.ino sketch files inside an example directory.

It all looked very promising at first glance but a closer look deflated the initial enthusiasm. The API only had commands for servo position, nothing for continuous rotation mode which is how Sawppy’s six wheels roll on the ground. And looking under the hood inside the code, the serial communication header is in the wrong format. The first two bytes are LewanSoul identifiers 0x55 0x55 as expected, but the third byte is length, not servo ID.

Digging a little deeper, I realized despite its location in the LX-16A Bus Servo subdirectory of LewanSoul’s Dropbox, this Arduino library was not for controlling LX-16A devices. They are, as the file name stated (but I overlooked) intended for their LSC line of controller boards for standard RC servos, not the serial bus servos.

Sadly, this promising-looking Arduino library will not help me.

Code for LX-16A servos actually lived in a different folder: bus servo communication routines held Arduino sketches matching the expected protocol. However, they were written as individual one big flat *.ino file, and not written as an Arduino library.

This is fine for sample code, but not well suited to be part of a larger project. It looks like I’ll need to learn to how to write an Arduino library after all, either to convert this LewanSoul sample code into a library or create my own from scratch (again).

Taking An Arduino Crash Course

Now that I’ve got the first few basic experiments up and running on my Arduino compatible board, I should invest a little time into learning what I’m dealing with here. Fortunately there is no shortage of informative pages on the web to take me beyond the simplistic “Hello World” blinking LED demo for an Arduino Uno. At the end of that tutorial, Arduino point the user towards to either further practice with the desktop IDE or go browse the project hub. I found the former lacking in technical information I desire and the latter was mostly irrelevant to the project idea I have on hand.

I then turned to one of my favorite resources: Adafruit’s extensive tutorials. Specifically their Arduino learning center. To get a grounding on what’s actually on an Arduino Uno board, “Lesson #0” orientation is a great start. For a little more advanced information on Arduino Uno hardware (and how it has evolved since the initial release) their hardware tips, tricks, and techniques was quite informative.

But the computing hardware was never the core strength of the Arduino platform, it was the extensive ecosystem of code libraries. These libraries allow users to assemble code modules together like LEGO pieces to build projects. People don’t have to know every nut and bolt of how to write software for everything, because it has already been done and available as an Arduino library.

The selection of Arduino libraries has grown enough there’s a dedicated library manager to keep things under control, and of course Adafruit has a walkthrough for the library manager as well. At this point I already saw how to interface with a simple potentiometer joystick, and I knew there exists a servo library for controlling standard RC servos. I also saw LewanSoul offers Arduino library to control the LX-16A servos. In theory, these code libraries should let me build an Arduino-based Sawppy controller with minimal coding. Let’s find out if the theory matches practice…

Obsolete Arduino Board Is Alive And Reading Analog Joystick

Learning Arduino has finally moved from a back burner to the front, and as a first step I finally unpackaged a years-old purchase of an Arduino Uno compatible board. Enough years have passed that particular board has become obsolete, but the Arduino ecosystem is still going strong so chances are good that I can still use the board to learn.

The first step with new hardware is always testing out some sort of a “Hello World” demo program to make sure the basics are working. When it comes to playing with electronics hardware, the popular choice is to blink a LED. This is such an entrenched thing that Arduino has designed a LED into their boards perfectly suited for the purpose, and my Arduino-compatible board has copied that arrangement.

Following the “Getting Started” guide for an Arduino Uno, I installed Arduino’s Desktop IDE. The basic example blink program was only a few clicks away, and an Arduino Uno was already selected as the target board type. Once I selected the serial port to use for communication, I was able to click on “Upload”. After a few seconds, I could see the test LED blinking on my board. It lives!

Success of that fundamental test gave me confidence to move on and add some hardware. I had bought some small joystick modules for this purposes of building my own Arduino based controller. Like most joysticks, they are built around a pair of potentiometers which made them an easy match for Arduino joystick tutorial.

OSEPP Uno R3 Plus with joystick

As many reviewers warned in that Amazon product listing, these joystick modules are very sensitive to movement. Their electrical range of motion is a surprisingly small subset of their actual physical range of motion. In other words, the potentiometers reach their minimum/maximum electrical values when the stick has only moved barely a third or halfway into its physical range of motion. This will be good for quick reaction movements but not as good for fine pitched movement.

These joysticks might not be the best ones for the job of rover control, but they will work well enough for continued Arduino exploration.

Finally Opening My Arduino Compatible OSEPP Uno R3 Plus

With my newfound motivation to get rolling in Arduino programming, I am finally going to open up the plastic blister pack of my OSEPP Uno R3 Plus. I must have bought this item when it was on sale somewhere, thinking I would get into Arduino programming but ended up letting it sit on a shelf for years.

OSEPP Uno R3 Plus blister pack

Today the product web page lists it as a discontinued product whose production ended almost three years ago in June 2016. The packaging backside pointed buyers to the url www.osepp.com/boards which is not even a valid URL anymore and returns a HTTP404 error page instead.

OSEPP Uno R3 Plus specifications

If this had been a proprietary product I would have been worried if I could even use it anymore. But since it was based on Arduino, an open source product, I was not as worried. Based on its name and physical appearance I guess it was a derivative of the Arduino Uno, which is still an active part of the Arduino product line in Rev3 form.

OSEPP Uno R3 Plus PCB

The exterior dimensions of the circuit board look identical, as are the mounting holes, in order to be compatible with the Arduino shield ecosystem. Comparing it against the standard Arduino Uno I see a few modifications elevating this product above a mere clone. The power jack looks the same but the USB connector is different. Its reset button has been moved to make way for a connector labelled I2C. I see four surface mounted LEDs in the same place as the standard Arduino Uno, which will be useful as I recall the Arduino “Hello World” blinks one of them.

The only thing I’m not terribly thrilled about is the fact the processor is a surface mounted chip instead of socketed DIP of the standard Uno. A socketed chip would be easy to replace if I should damage it in some way, with this surface mounted chip I’m pretty confident I’d need to buy a new board.

I see a little bit of manufacturing residue on the circuit board, possibly solder flux that was not completely cleaned off. That and a few other cosmetic blemishes did not worry me in regard to board functionality. It looks ready to go, so let’s plug it in and see what happens.

I Found My Motivation To Enter World of Arduino: Make Sawppy Easier

When talking to people about fun electronics projects, it has come to people’s surprise that I have yet to do anything with an Arduino. It is the platform of choice for introduction to hardware computing and how many people got started in this hobby, but for one reason or another I never went through that phase.

Generally, if I need something with computing power or network connectivity, I use a Raspberry Pi 3. If I need low-level control over precision timing, I use a PIC. Sometimes those two are paired up, like our VFD driver board project. An Arduino’s capabilities fit in between those two platforms, but as I already have proficiency in coding for a Pi and for a PIC, it doesn’t leave much motivation for me to learn Arduino. But it’s something I kept in mind, expecting that one day an Arduino’s beginner friendliness will be an asset for me to build a project with one.

That opportunity has surfaced!

backyard sawppy 1600

As I took Sawppy around to various events, I had many opportunities to talk with people who show interest in a DIY motorized Mars rover model. My own personal ambition is to make Sawppy autonomous, but not everyone shares that goal. I learned that many people would be content with a remote controlled rover. Furthermore, I’ve seen a lot of interest in parents who wanted to gauge if Sawppy is a good project to build with their children. And in this scenario, my SGVHAK rover software running on a Raspberry Pi is far more complex than strictly necessary.

For this audience, a simple Arduino-based rover control system would fit a niche separate from that of a Raspberry Pi rover control scheme. It will be less powerful, but will also be lower cost and more approachable as a learning exercise for beginners.

So for the sake of making Sawppy more accessible to everyone, I’m going to start investigation into an Arduino-based control scheme.