OMower

KO | EN

gitlite — search

#javascript #ai #typescript #llm #golang #android #machine-learning #rust #deep-learning #linux #nodejs #windows #awesome #pytorch

(★ 10)

SDK for open-source open-hardware 2/4 wheels robots platform

OMower Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

OMower project is open-source open-hardware wheeled robots platform with 32-bit ARM ATSAM3X8E
microcontroller, same as in Arduino Due. The project compiles under Arduino IDE (requires patching standard
ATSAM platform library files to support all GPIO lines of the MCU).

The project was inspired by ardumower project (https://github.com/Ardumower/ardumower) and uses few bits
of its code.

FEATURES

Control, measurements and navigation routines for wheeled robots (primarily lawn mowers but not limited to)
with wire perimeters, sonars and other sensors, GPS or RTK GPS (centimeters-level precision).

Support for 2 (with third support wheel) or 4 motors platforms. Brushed motors supported with Polulu Dual
MC33926 (onboard) or IHM12A1 controllers (external), brushless motors will require external ESCs (controlled
by PPM/servo output).

Includes PPM/servo output for the brushless mowing motor (or you may use onboard for brushed mowing motor)
and step-motor drivers for cutter's height adjusting.

Supports many communication ports of ATSAM3X8E with onboard connectors to connect almost everything.

It may operate with pure pfodApp (or Modbus) user interface but has limited support for Robot OS (ROS).

HARDWARE

The board is based on ATSAM3X8E-AU MCU in 144-pins LQFP case (for arduino IDE it looks like Arduino Due
without "programming" port).

Power subsystem includes step-down charging regulator (up to 4A charging current) and step-up for solar
battery, bi-stable relay for emergency shutdown. Has 3 switching regulators to provide 3.3V and 5V to
multiple internal and external devices, precise linear regulator for analog parts.

Supports battery voltages up to 28 volts, has onboard switching regulators for external charger and solar
panel.

Three ACS725-30 current hall sensors to measure consumption and charging currents up to 30A real-time.

Multiple connectors for everything mower or any other robot needed with 5V->3.3V logic conversion (6x HC-SR04
sonars, 5 odometers, 3 serial ports, 4 wire perimeter sensors, two bumper sensors, lawns and drops sensors,
two temperature NTC termistors connectors, two SPI ports, LEDs, button and more).

Has I2C buffers (both 3.3V and 5V versions) to connect multiple I2C devices, USB port (firmware upload),
external 12-channel ADC MAX11617 (connected to I2C).

Has port for Orange PI Zero (for RTK GPS and Wifi connectivity, firmware upload), can be replaced by any
Wifi/Bluetooth adapter connected to serial port of MCU.

Multiple PPM/servo outputs for external stuff with standard 3-pins connectors.

Note, board requires external components: external IMU GY-80 board or MPU-9250 board, external motors
controllers and steppig motor driver boards. External charger voltage must be 6 volts higher than
maximum battery voltage (i.e. for 14.6V LiFePo-battery it must provide 20..34V).

Latest version is 3, in v4 version the board will include FRAM chip to store settings/waypoints/etc (as
ATSAM3X8E's flash is getting erased when uploading new firmware) and onboard IMU MPU9250.

Schematics and KiCad development files for the 4-layers board is in hardware folder. Version 3 board
variant can be ordered from oshpark: https://oshpark.com/shared_projects/ILEdXK2T

SOFTWARE

The SDK's main goal is isolate hardware stuff from higher level software and easy development of wheeled
robot platforms. It configures timers, interrupts, ADCs and other stuff to provide API to develop software
without underlying hardware knowledge. It provides basic control and navigation stuff (like moving between
points with RTK GPS), external ports (like sonars or PPM/servo stuff), measurements for ADCs (internal and
onboard MAX11617), etc.

Look omower-*.h header files for API classes, check OMower_Simple firmware to see how to use them.

OMower SDK includes patches (see *.patch files) for standard ATSAM* libraries to support all GPIO's of
ATSAM3X8E (compatible GPIO mapping with Taijuino Due Pro). Without them you won't able to use all ports of
the OMower board!

Some of OMower stuff is not compatible with other arduino libraries, check restrictions.txt file.

Decawave DWM1000 radiotags navigation support is not tested yet, requires DWM1000 tags connected to MCU with
MyRangeTag software, see https://github.com/vasimv/MyRangeTag

USAGE

Place OMower folder into ~/Arduino/libraries, choose your board in omower-defs.h (currently supported boards
are OMower v3 and Arduino Due + IHM12A1 motor controller. Remember to patch ATSAM hardware library files to
use all GPIOs of ATSAM3X8E MCU.

Clone https://github.com/vasimv/OMower_Simple and  put its folder into ~/Arduino, compile and upload. Use
pfodApp to control the robot.

ROS support

At this moment, ROS support is limited and includes sending some of sensors data to ROS (with *MultiArray
messages but i planning to convert them to standartized message types), /cmd_vel support and routing debug and user
interface to ROS topics. See OMower_Simple firmware example on how to enable ROS in your firmware.

HOW IT WORKS

OMower software must define all needed objects, set pointers to other objects where it needed (like
gps object needs to set pointer to imu object), call all begin() functions of objects (hardware init, called
just once), then sets values for objects parameters and call init() functions (software init, can be
called many times to reset the object's hardware), define poll10/20/50 hooks functions to call objects
poll*() functions from there (see OMower_Simple.ino for example).

One of most important classes is motors object (see omower-motors.h), it controls motor drivers from its
poll10() function. User just calls functions roll/move (to simple turning or driving in a specific
direction) or rollCourse/MoveCourse to drive with navigation by something (compass, gps, etc).

IMU stuff (compass, gyro, accelerometer) are read in imu object (omower-imu.h) by its poll50() function.
It does filtering/calculation and provide angle values for compass and pitch/yaw/roll in degrees
(see omower-imu.h). The imu object is daughter class of navThing class (see omower-root.h) that means
it has readCourseError() function, so it can be used for navigation by motors object. Currently it supports
navigation by compass angle.

GPS object is daughter class of navThing too, so it supports navigation. All coordinates are stored in
int32_t values (so, 18.3495,-68.5960 will be 183495000,-685960000 actually) to improve precision (otherwise
it would need large float class which does not exists in arduino framework). The user software must
interface with a GPS receiver and feed NMEA lines from it to gps::parseString() function or raw
coordinates to gps::settCoords() (see omower-gps.h). In precision mode (when centimeters-precise
coordinates are used) - the gps object calculates robot's true coordinates using offset of GPS's antenna
(distance from robot's center and angle).

Power object (omower-power.h) handles power stuff (battery, solar panel and charger regulators) and
provides human-readable values of voltages and currents.

Mow object (omower-mow.h) manages the mowing motor(s) and its actuator (if have) to adjust cutting height.
Note, currently it supports only PPM regulation on PWM-E output (brushless motors ESC connected to it), but
will support brushed motors too (in 2 wheel motors + mow motor configuration).

Perimeter object (omower-perimeter.h) supports up to 4 wire perimeter sensors (same as for ardumower, just
inductor+analog amplifier).

Serial object (omower-serial.h) handles communication with serial ports (as you can't use arduino's
objects for that because possible interrupts conflicts). It has also better printf() functions which
supports %f/%g for floats. UART (Serial.*) interface works with DMA (through built-in PDC) with huge
output buffer (2048 bytes, can be changed in omower-debug.h), so debug output function won't cause
slow-downs.

Sonars object (omower-sonars.h) handles HC-SR04 sonars (up to 6). It returns sonar's reported distance
(in centimeters) through its readSonar() function. Since motors routines do not check for any obstacles
during movement (except overcurrent on motors drivers), the user software must check sonars and bumpers
to avoid obstacles and move around them.

At start of initialization chassis object (omower-chassis.h) initializes interrupts. This is most important
task as almost all of OMower's stuff is done through interrupts hooks. It configures TIM7 to generate
interrupts 100 times per second.

At every TIM7 interrupt, it reads 12 channels of MAX11617 ADC to "uint16_t adc11617Arr[]"
(defined in max11617-adc-scan.h), this array is accessed from other OMower's objects (like power object, but
of course you can read its values directly).

Every second cycle of TIM7 interrupt it calls user's poll50() hook, at every fifth - poll20() hook, at
every tenth - poll10(). User's software must define these functions, set it through
chassis::setHooksPoll() function and call all other objects poll10/20/50 functions from there. By default,
to call hook functions it creates software interrupts for each kind of them (defined symbol
USE_SOFTWARE_INTERRUPTS in omower-defs-omowerv3.h), so they are running asynchronous. Without
USE_SOFTWARE_INTERRUPTS - poll50/20/10 hooks called after each other and you are limited to 20ms total time
for all of them (OMower SDK functions were optimized to comply with that time and software interrupts
can be turned off but if you place some other CPU hungry stuff in it - you will need software interrupts).

It was possible to create automatic binding for poll functions (so user wouldn't need to call all
objects poll*() functions from firmware code), but it was decided not to do so to simplify the SDK
internals.

All internal ADC channels of ATSAM3X8E are read by separate TIM5 interrupts 38461 times per second to the
"adcArr[]" array (see due-adc-scan.h for its structure). This array is accessed by other omower objects
from their poll10/20/50 functions, so no need to read it directly (but you still can do). Note, it is
possible to add circle buffer to every channel read, so you won't miss any of value (this method is used
in wire perimeter class for FFT filtering of the perimeter signal) through adcAddChannel()
function (due-adc-scan.h).

PWM and TCC (in PWM mode) outputs are configured through pwmServo object (omower-pwmservo.h), don't use
other methods to modify their output as it may conflict with OMower code. Since the code uses some
MCU's timers, you won't able to use these for other things (Timer0, Timer6, Timer8 in pwmServo, Timer5 in
due-adc-scan.cpp, Timer7 in chassis). Usually, nothing uses them but some of arduino libraries do (like
Servo library, which you wouldn't need as there is pwmServo object).

Debug function debug() is defined in omower-debug.h. By default, it sends its output to Serial device, has
ability to set priority for debug messages (so low-priority stuff won't be send at all).

There are some other objects which are easy to understand (omower-rtc.h for RTC clock, omower-current*.h for
current sensors, omower-odometry.h for odometry sensors), please, look their header files and OMower_Simple
firmware code if you want to know how they are used.

OMower

OMower Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

OMower

OMower Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README