I have re-built my old balancing robot using a single Arduino Mega instead of my previous solution using three different Arduinos. A better more optimized solution. Schematic and source code is available on the robot page here: http://axelsdiy.brinkeby.se/?page_id=1845
This video has gained some attention on youtube, and I think that is why I get at least one email every other week from people asking about the code and schematics for this robot. I have not shared the code of any details about this robot since it is very poorly made and coded. The robot uses multiple Arduinos just to keep the balance and drive the motors, later I also added another Arduino to manage the Ultrasonic sensors and some other stuff. There was also a Raspberry Pi that I planned to use for computer vision experiments, I never came around to doing that using this robot.
Now when I know a lot more about self-balancing robots, and Arduino programming and DIY robots in general, I decided to make a new version of this robot. I new complete rebuild of it. My intention is to make the robot less complicated and also better. I stripped down almost everything in the robot and started over. Still using the same old wooden chassis. The new version is based on a single Arduino MEGA R3 controlling everything in the robot. It reads the MPU6050 IMU, makes all the filtering and balancing calculations, and drives the motors using hardware timers for maximum precision. The new code for this robot is heavily based on the code for my “mini balancing robot”, with some improvements, more info about that robot here. I still use the same old stepper motors, model airplane wheels, and “Big Easy Driver” -stepper motor driver boards. The Arduino MEGA also controls and reads four HC-SR04 ultrasonic sensors using Interrupts. Those sensors are used for obstacle avoidance.
The new version of the robot works now. It balances and drives around avoiding obstacles, but I still have a few things to fix with the code. I want to add a pushbutton for control and a buzzer for feedback, I should also add battery measuring and implement a low voltage cut off to prevent damage to the battery.
I hope to release I video of the robot together with the code and schematic in a couple of weeks.
The servo seen in the pictures is not and will not be implemented in the first version of the code, but the intention is that the servo should be used to make it possible for the robot to raise itself up and start balancing on its own. Maybe I will also ad some sort of remote control since it is a frequently requested feature, But that will be in a later version.
This video shows a robot I have built that is driving between two waypoints using GPS.
I built this robot last summer, about a year ago. Back then, I never really managed to the software part of the robot working. The weather became worse outside as the fall came, and a lost interest in this project and started working on other things instead.
I wave written all the code myself, apart from the functions used to calculate course and distance between GPS waypoints. I used functions from the TinyGPS library for that. The code runs on an Arduino Due, the robot is using PID control to steer towards the waypoints. The robot uses a combination of GPS-course and integrating the signal from a yaw-gyro to determine its current course. The robot also has a compass, but it does not seem to work very reliably, therefore I do not use it. The robot also has sonar and other sensors, but they are not used in this video. Expect more videos and info about this robot in the near future.
I added procedural water in the “Procedural terrain engine”.
Normally when creating water one often use tiling Du-Dv and Normal textures to create distortion effects and lighting. This is how I did it in the Realization Engine. Here I am generating those textures procedurally on the GPU in real time instead. This allows me to adjust diffrent parameters to change the look of the water. It also removes the repeting patterns in the water that are clearly visible when using texture images that are loaded from the disc.
Procedural terrain engine is my own graphics engine I have written In C++ using OpenGL, GLSL and GLFW to experiment with procedural generation of different typs.
I worked on this project mostly during this summer with the purpose of learning more about the game engine Unity and game development in general. In the last couple of weeks I have tried to finish all the features I stated to implement, and make a playable game out of it. This Game is also my entry in the annual “LiU Game Awards” competition.
You can download the game and try it for yourself here: http://robotandrocksgame.brinkeby.se
This is a demo I made using C++, OpenGL and GLFW. It is a proceduraly generated landscape in which the user can “walk around”. The terrain is generated using Simplex-noise and is made up of chunks that are loaded and removed as the user walks over the terrain. It is possible to walk infinity (or at least very very far) in one direction without reaching any edge or crashing the program. The chunks are rendered in different levels of detail depending on the distance from the camera to improve performance.
This is a project I made together with two others students: Mikael Lindhe and Eleonora Petersson. This project was made in the course “Modelling Project TNM085” at Linköping University. The video demonstrates two pieces of cloth that are simulated in two different ways.
The first cloth is represented with particles that are connected with each other using constraints. This mean that whenever the cloth moves, the distances between the particles are corrected to make the cloth retain it’s shape. This is the “usual” method for simulating cloth in computer games.
The second cloth is simulated using a method where the particles are connected with each other using springs. When the cloth moves, forces are applied to all particles to correct them to there original distances from each other. This method proved to be more computationally heavy and less stable then the first method.
I was mainly working on the graphics part for this project, while the others focused more on the simulation part. It was the first time I developed a basic rendering system for modern OpenGL in C++ from scratch. It was also the first time I made a program that updates vertex buffer data for an object every frame.
I made a new videon showing how I decorate a small island to demonstrate the new improved world editor mode. Now the user can place any abject as well as moving and rotating them. Objects and also be deleted. The world can be saved to a file from the editor. At startup, the program looks for a save file in the same folder as the executable file, if no save file is found, a default file is loaded. The video also shows some post processing effects I have implemented.
Download an try it yourself: http://sor.brinkeby.se/
I have added a simple editor mode in my graphics engine that allows me to move and rotate entities with the mouse cursor.
This works by casting a ray from the camera, trough the mouse cursor, into the world. To select objects, the distance from the objects local origin to the mouse ray is calculated using linear algebra, if this distance is small enough the object is selected. Then the intersection point between this ray and the terrain is calculated using binary search, and used to position the selected object.
Download version 22 and try it yourself: Realization Engine download page
Double jump using [Space] to begin flying mode. Use space and [Shift] to fly up and down. Hold down [Alt] to free the mouse cursor to interact with objects. Click and drag objects with the left mouse button to move them. Click and drag with the right mouse button to rotate objects. Press the center mouse button to spawn a new “physics-barrel”.
Steam Digger is a game that I made in the course “TDDD23 Design and Programming of Computer Games” at the university. The game is inspired by an old browser-game called “motherload” the I played a lot when I was a kid. My version is made using Java, libGDX and Box2D. This was interesting to make because if was the first time I used an actual game-library any physics engine to make something. I did not have as mush time as I wanted to spend on this project. There were some features and detailed that were planed, put never added. I think it turned out pretty well anyway. Maybe I will finish this project someday.
Download the game and try it for yourself: http://steamdigger.brinkeby.se/