Wheel Going in the Wrong Direction – RVIZ2 and FoxGlove

Hi everyone,

I hope you’re having a good break! I’m currently following this tutorial and messing around with a diffdrive robot. After making a few changes I noticed that my simulations were playing up. Strangely, the robot itself was still working perfectly fine.

The problem I was having was that even though my robot was driving forward the simulations seemed to think that the left wheel was going backwards. Initially I suspected this was an issue with my robot’s definition but even when returning to a known working state the issue persisted.

Eventually, I realised that this meant it had to be a hardware issue. I am using an Arduino and two L298N motor controllers for the motors that run my wheels. The arduino then publishes my encoding counts over serial.

To debug this setup, I used miniterm to communicate with the arduino and view the serial output. To get this going I had to track down which serial port had the arduino connected:

ubuntu@ubuntu:~/robot_ws$ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Alternatively, ls /dev/ttyUSB* would also work. I also needed the baud rate which is set to 57600. This allowed me to connect, move the motors forward and also see the encoding counts:

ubuntu@ubuntu:~/robot_ws$ miniterm -e /dev/ttyUSB0 57600
--- Miniterm on /dev/ttyUSB0 57600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
e
0 0
o 255 255
OK
e
-5531 5572
e
-8120 8222
e
-8120 8222

The issue became obvious with the left wheel outputting a negative value. The fix for this was pretty simple. Reversing the pins outputting the encoding count for the left wheel reverses the counter. Re-running the miniterm test showed both wheels with a positive count:

ubuntu@ubuntu:~/robot_ws$ miniterm -e /dev/ttyUSB0 57600
--- Miniterm on /dev/ttyUSB0 57600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
e
0 0
o 255 255
OK
e
8146 8211

Using INA219 (GY-219) with the Raspberry Pi

Hi everyone,

I’ve just setup an INA219B Voltage/Current sensor on my RaspberryPi. Just thought I’d link the tutorials and libraries I used – there’s a lot of really useful info out there.

Install the following library via git: https://github.com/chrisb2/pi_ina219
sudo pip3 install pi-ina219

Follow this tutorial: https://www.rototron.info/raspberry-pi-ina219-tutorial/

Misc Notes

  • Common ground is required
  • Vin – and Vin+ are attached to +, neither goes to ground

Custom Sensor Address
na = INA219(SHUNT_OHMS, MAX_EXPECTED_AMPS, address=0x41)

Can be configured via the following:

https://www.rototron.info/raspberry-pi-ina219-tutorial/
https://www.rototron.info/raspberry-pi-ina219-tutorial/

Enable Low Power Between Reads
ina.configure(ina.RANGE_16V)
while True:
print "Voltage : %.3f V" % ina.voltage()
ina.sleep()
time.sleep(60)
ina.wake()

If you’re getting the following error:

OSError: [Errno 121] Remote I/O error

Run the following command:

i2cdetect -y 1

And check to ensure that your device is showing up on 40. If it’s a different number you’ll just need to update the address in your code e.g. (0x40, 0x41, etc.)

Mini-360 DC-DC Buck Converter – Incorrect Voltage 10v Instead of 5v

Hi everyone,

I’ve been playing around with a few DC-DC buck converters similar to these ones: https://www.amazon.com.au/UEB-Power-Converter-Module-Supply/dp/B078CXHWXC/ref=sr_1_fkmr1_1?ie=UTF8&qid=1519030369&sr=8-1-fkmr1&keywords=mini+360+buck+converter

I had expected 5v output from my 12v supply but when I hooked it up to a multimeter I found I was getting just over 10v. This would fry pretty much everything in my circuit so I was pretty worried.

After a bit of research, I came across a thread on eevblog that mentioned a screw for adjustment. Looking closely you can see that there is a small screw on the side of the chip. Turning this quarter of a rotation anti-clockwise put mine at exactly 5.04 volts.

A few other small tips:

  • The thread seems to indicate that some models require a lot more turning (up to 30 seconds for one poster).
  • I had to push down fairly hard to get it to actually turn the part underneath instead of just the metal cover

Hopefully this helps someone else out!

Eevblog: https://www.eevblog.com/forum/beginners/dc-dc-buck-converter-step-down-module-lm2596-power-supply/

Thanks,
Chris

Duinotech Hall Effect Sensor with RaspberryPi

Hi everyone,

This is just a quick post to cover how the Duinotech hall effect sensor module (XC-4434) can be hooked up to a RaspberryPi.

Sample Code

The code below will output a zero when the sensor is activated by a magnet, otherwise a zero.


import time
import datetime
import RPi.GPIO as GPIO

# Define constants
BUCKET_HALL_EFFECT_SIG_PIN = 14

# Setup GPIO pins
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(BUCKET_HALL_EFFECT_SIG_PIN, GPIO.IN, pull_up_down=GPIO.PUD_UP) # Important

while True:
print(str(GPIO.input(BUCKET_HALL_EFFECT_SIG_PIN))
time.sleep(0.5)

Wiring

Example

When near a magnetic field the light on the sensor will turn on. If you’re using the sample code above, a zero will be shown when close to a magnet, otherwise a 1.

Misc

Purchased from: https://www.jaycar.com.au/arduino-compatible-hall-effect-sensor-module/p/XC4434

Spec Sheet: Z7275

Compass Only Works on Pins 10 and 11 – Arduino/Software Serial

Hey everyone,

A bit of a confusing issue I ran into today. I couldn’t get my compass to work on any pins other than 10 or 11. Thankfully, there’s a fairly logical explanation:

Not all pins on the Mega and Mega 2560 support change interrupts, so only the following can be used for RX: 10, 11, 12, 13, 14, 15, 50, 51, 52, 53, A8 (62), A9 (63), A10 (64), A11 (65), A12 (66), A13 (67), A14 (68), A15 (69).

I ended up using pins 50 and 51 and it all worked fine. See the following links for more info:
https://www.arduino.cc/en/Reference/softwareSerial
https://arduino.stackexchange.com/a/35719/37451

UnicodeDecodeError on RaspberryPi – Python

Hey everyone,

I ran into the following error while trying to read serial input on a Raspberry Pi hooked up to an Arduino via USB:

UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0za8 in position 0: invalid start byte

The solution was as follows:

#buffer_string = ser.read().decode('utf-8')
buffer_string = ser.read().decode('utf-8', errors='replace')

Thanks to the following link: https://github.com/OpenBCI/OpenBCI_Python/issues/24

Arduino GPS – Ublox NEO-M8N Flight Controller GPS w/Protective Shell for PIX PX4 Pixhawk

Hey everyone,

I recently purchased this GPS unit on ebay: http://cgi.ebay.com.au/ws/eBayISAPI.dll?ViewItemVersion&item=272492032614&view=all&tid=1865626885017

Unfortunately, I didn’t do a lot of research before getting it and had a bit of trouble finding any spec sheets or documentation. Just in case anyone else has the same problem I’ve listed out everything I needed to get it running below.

This is the wiring info you’ll need for an Arduino:
– VCC: red
– GND: black
– TXD: yellow
– RXD: white
– SCL: green
– SDA: blue

And while this post is mostly targetting Arduino, the following wiring can be used for a RaspberryPi3:
– VCC: red => pi 3.3v
– GND: black => pi gnd
– TXD: yellow => pi rx (GPIO15/Pin #10)
– RXD: white => pi tx (GPIO14/Pin #08)
– SCL: green => pi scl (GPIO3/Pin #5)
– SDA: blue => pi sda (GPIO4/Pin #7)

For the Pi, the following commands might come in handy if you’d like to see the output in the console:

# Set the baud rate
stty -F /dev/ttyS0 9600

# View output
sudo cat /dev/ttyS0

The default baud rate was 38400.

This is the example I ended up using to get a quick test up and running. Ensure that you map the rx and tx pins correctly (arduino tx to gps rx, arduino rx to gps tx).


v#include
#include
/*
This sample sketch demonstrates the normal use of a TinyGPS++ (TinyGPSPlus) object.
It requires the use of SoftwareSerial, and assumes that you have a
4800-baud serial GPS device hooked up on pins 4(rx) and 3(tx).
*/
static const int RXPin = 11, TXPin = 10;
static const uint32_t GPSBaud = 38400;

// The TinyGPS++ object
TinyGPSPlus gps;

// The serial connection to the GPS device
SoftwareSerial ss(RXPin, TXPin);

void setup()
{
Serial.begin(115200);
ss.begin(GPSBaud);

Serial.println(F("DeviceExample.ino"));
Serial.println(F("A simple demonstration of TinyGPS++ with an attached GPS module"));
Serial.print(F("Testing TinyGPS++ library v. ")); Serial.println(TinyGPSPlus::libraryVersion());
Serial.println(F("by Mikal Hart"));
Serial.println();
}

void loop()
{
// This sketch displays information every time a new sentence is correctly encoded.
while (ss.available() > 0)
if (gps.encode(ss.read()))
displayInfo();

if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(F("No GPS detected: check wiring."));
while(true);
}
}

void displayInfo()
{
Serial.print(F("Location: "));
if (gps.location.isValid())
{
Serial.print(gps.location.lat(), 6);
Serial.print(F(","));
Serial.print(gps.location.lng(), 6);
}
else
{
Serial.print(F("INVALID"));
}

Serial.print(F(" Date/Time: "));
if (gps.date.isValid())
{
Serial.print(gps.date.month());
Serial.print(F("/"));
Serial.print(gps.date.day());
Serial.print(F("/"));
Serial.print(gps.date.year());
}
else
{
Serial.print(F("INVALID"));
}

Serial.print(F(" "));
if (gps.time.isValid())
{
if (gps.time.hour() < 10) Serial.print(F("0"));
Serial.print(gps.time.hour());
Serial.print(F(":"));
if (gps.time.minute() < 10) Serial.print(F("0"));
Serial.print(gps.time.minute());
Serial.print(F(":"));
if (gps.time.second() < 10) Serial.print(F("0"));
Serial.print(gps.time.second());
Serial.print(F("."));
if (gps.time.centisecond() < 10) Serial.print(F("0"));
Serial.print(gps.time.centisecond());
}
else
{
Serial.print(F("INVALID"));
}

Serial.println();
}

Output should be something like this:

DeviceExample.ino
A simple demonstration of TinyGPS++ with an attached GPS module
Testing TinyGPS++ library v. 0.92
by Mikal Hart

Location: -27.427371,153.028945 Date/Time: 9/10/2017 06:04:21.40
Location: -27.427371,153.028945 Date/Time: 9/10/2017 06:04:21.40
LocatiaonfTGS+wh atahdSmlesiTiGS+bay .2b a at
ain Da/ie/ ai .Da/Te 1tion: -27.427371,153.028945 Date/Time: 9/10/2017 06:04:21.60
Location: -27.427371,153.028945 Date/Time: 9/10/2017 06:04:21.60
LocaS+bay .2b a at
ain Da/ie/ ai .Da/Te 1tion: -.aeTm1.
ti:.atTm:7cation: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:21.80
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:21.80
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.00
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.00
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.20
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.20
Location: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.40
Locat/Te:/ an:3aTi: /1ain.atTm:7atn 3Dtie 1.cto.3teim 1.
ti: .aTim1aton: -27.427370,153.028945 Date/Time: 9/10/2017 06:04:22.40
Location: -27.427368,153.028945 Date/Time: 9/10/2017 06:04:22.60
Location: -27.427368,153.028945 Datn 3Dtie 1.cto.3teim 1.

One final thing to note is that the blue light will start to flash once the GPS has a lock. You’ll need a pretty open space, mine didn’t work inside but got a lock within 60 seconds outside.

Let me know if you have any questions or links to better doco!