Related lists

Description

I wanted to do something practical, challenging and educational for my final year univertsity project. I didn't know a huge amount about the practical side of control engineering or electronics but I was inspired by what other hakers/makers have managed on youtube etc with this type of robot. During my background research phase, I noticed was that many of the self-balancing robots do not fulfill a practical purpose; they are just cool. So I am aiming to adapt existing open-source projects and make a self balancing crane style robot. The project was started in September 2018 and aims to be complete by April 2019. Currently working on getting this page up to date with control script files, circuit diagrams, photos and videos...

Details

Please scroll down to see the project log to see my latest progress. I will provide links to testing videos there.

The concept drawing of the robot is the best explaination of what I am trying to build, and why I have called it "Straddle Crane"...

There are 4 key deliverables of this project:

Build a robot capable of balancing (no position control or crane mechanism)

Develop prototype to be able to move around based on smartphone communication

Add crane mechanism to robot chassis so that the unloaded crane boom can move and the robot remains balanced

Project Logs

Please follow this link to see the final testing videos. The project is finished now and I will upload all resources needed to build the prototypes very soon. The thesis will be uploaded for those who are interested the academic side of the project or want to see the project conclusions in more detail.

I'm backposting here because I have been busy on my write up. I thought I should share the videos of the first tests of the 2nd Prototype on the day I managed to get the whole thing working. See this link for the google photos shared folder.

I have taken a break from updating this log due to the looming thesis deadline (29th April). I have finished the design work for my project so I thought I would share renders so you can understand the two prototypes I designed and built on this project more clearly.

Since last time, when I posted that I had completed the Prototype 2 chassis and crane design, I have been working on designing a robust soldered circuit to replace the breadboard (and all the trouble with shorting etc. it has brought). I have some nice time-lapses of the soldering and construction; once they have uploaded to my google photos I will post a link.

Breadboard and solered arrangement side by side... quite an improvement right? Circuit diagrams will be uploaded in due course.

With the completion of the sliding mechanism, it was time to build the entire prototype 2 chassis.

The aim of this prototype was to integrate a crane boom into the chassis.

The secondary improvements based on critisims of the first prototype were:

Clips to secure battery and reduce swinging about

Wires from stepper to be easily routed

Power switch to be connected to the robot frame rather than floating

After many late nights, the picture below shows the completed result.

Please see the link to a video of the operational crane mechanism!! LINK

My main goal now is to integrate this with the self balancing capability of the first prototype. I also intend to move from a breadboard to a soldered stripboard because this has been causing me many issues.

The crane boom design is based on that of a 3d printer; inspired by the prusas in the iForge. It uses a continuous servo and a rack and pinion to lift the boom. The design uses 3D printed bearings and bearing housings to locate the boom and allow sliding.

I had noticed that the accelerometer had a strange offset in addition to the gyro drift I had encountered. Therefore, I conducted some more rigorous tests to look at the signal to assess the gyro drift and the accelerometer readings simultaneously. The testing method was as follows:

With the code set to record the accelerometer angle, gyro angle & overall pitch angle...

1) Undisturbed testing...

Robot placed on stand

Reset the arduino

Start timer on my phone as soon as the serial monitor started outputting data

Immediately I could see that the data did not align with the experiment time (the data from both experiments apparently only went up to about 20s despite me knowing I recorded data for 30s). My conclusion was that the MPL (main program loop) must be exceeding its time limit; the code was taking longer to run than anticipated.

The accelerometer has a constant offset of around 10 degrees; this is unchanged by excitation and will be dealt with by centering the signal about 0 by subtracting the mean from this data.

Further experimentation to verify the above:

I made the MPL time period a variable and increased it from 4ms to 7ms and the result was as follows:

I subtracted the mean from the above data and took more readings:

As a result of the above changes, the robot needed some more PID tuning (MPL period resulted in new gain values needed), but looked very promising in terms of stability.

Because I am coming to the end of my project timescale, I decided to move on to the mechanical design of the crane system despite the remaining balancing perfromance issues. The robot works well enough for proof of concept.

After yesterday's attempt at adding steering to the robot resulted in some instability ( probably due to the added computational power of having seperate throttling variables). I decided to revert to the previous code and add only forwards and backwards control to see how this affected the stability.

I have solved my logistic problem by adding a string harness for the robot to my wired controller (you can sort of see it in the above picture), check out the videos to see how much easier it is making the testing; no more need for a friend chasing the robot around. The robot moves forwards or backwards by tilting itself into the direction it needs to travel. The results were very promising. Please see this video link.

The robot can drive in both directions but drives slowly in the direction against the way it tends to drift and slightly too fast in the other direction. I am fairly confident now that the robot will operate as intended when I sort these sensor issues out! Today I also conducted some more rigorous testing on the robot and have a good amount of data with repeats that I will analyse in the hope of sorting these issues out. I will post any significant progress on here.

Today I modified the code to give the robot some steering capability. This meant creating separate throttling variables for each motor whereas previously I had just one variable that controlled both motors simultaneously. Now when the joystick is pushed left or right the code adds to the left and subtracts from the right motor's PID value to result in different throttling between motors.

The robot can now steer but is much less reliable! Strangely, the robot has become less stable as a result of me adding this capability; it is nowhere near as stable as before with the same PID values. I am not sure why the tuning should be different but I suppose I have essentially doubled the computation needed in the subroutine than controls the motors. I have had some attempts at tuning with varied success. It is not being told to move forwards by the way, this is still an effect of drift I think. Please check out the videos below...

Discussions

Become a member

I have a few suggestions. If you find the stepper drivers are getting hot, you could heatsink them, or many stepper drivers will allow external FETs to be used. This would allow significantly more current while spreading the heat load out. Looking at the A4988 datasheet, it looks like using external FETs wouldn't be too difficult.

Also, gyro drift is very common. It is usually characterised in the datasheet. Using the accelerometer data in tandem with the gyro is a good way to improve the drift - if the gyro is changing but the accelerometer isn't showing movement, then you can assume it's drift. This is what "sensor fusion" is all about. Elecia White's book Making Embedded Systems touches on this subject, if I remember correctly. There are many libraries out there for sensor fusion but depending on your timeframe, you can always try writing it yourself! It's a bit of math, but nothing too difficult.

If you have any problems, feel free to message me! I'd be happy to help.

Thanks for checking them out Alexander. Just to clarify, on the latest video (8th March) could you notice any unhappy driver sounds? I switched to lower current stepper motors for that video and everything seems to be okay now...

Hi Alexander, many thanks for this comment. I think my stepper motor issues are largely fixed by me now using less current demanding stepper motors. I had never heard of FETs, could you provide any resources where I can learn about using these with the stepper drivers? I can see this could be very helpful for upscaling this robot or improving its perfromance.

Regarding the gyro and accelerometer issues, I made a post recently dated 15.03.2019 discussing the drift and accelerometer issues I was facing and a more rigorous experiment I conducted in an attempt. I only posted my accelerometer data but I collected data for 3 angles simultaneously: accelerometer angle, gyro angle and overall pitch angle that is obtained through (gyro_angle*0.99 + 0.01*accelerometer_angle). I can publish the data if you think it would be helpful? The gyro angle has an "average drift value" subtracted from it every loop; this value was obtained through simulating 500 main program loop periods during the set up procedure (conducted whilst robot is lying down) and taking the mean drift per loop. So I think I am already embodying some of your suggestions. My worry is that adding a more complicated filtering algorithm could slow my code down.