Recently I was reminded of the Collatz Conjecture during a lecture.
Recently I was reminded of the Collatz Conjecture during a lecture.
You have to give it to Microsoft, they’re doing some pretty impressive stuff these days. Last night I got the latest Creators Update, and took WSL for another spin. It now ships with Ubuntu 16.04 and a tonne of improvements. We can now launch Windows applications from bash!
Over a year ago, for some reason I created my blog on Blogger. Even at the time, I knew I’d eventually want to get my own domain, host, and build my website on something better. Well recently I’ve finally done it and it was surprisingly easy.
It seems like it was only yesterday when I first downloaded Arduino 1.0.1, when I first discovered the magical world of embedded programming. I clicked on the upload button … “serial port not found.”
The boards arrived yesterday –surprisingly quick for OSHPark.
After adding the laser, I quickly made a test program that sends the estimated range of the object via serial to the computer. The sensing algorithm on theCMUcam5 only detect the laser up to a distance of around 80cm. What’s worse?
I decided to begin making a laser rangefinder today using a camera implementation. This method is quite simple compared to the complex circuitry and ICs needed for a TOF (time of flight) implementation–light is very fast and ridiculous precise and accurate timing is required for TOF.
So today I finally decided to design a PCB for the HM-11 Bluetooth module. At $10 dollars a piece (and as low as $2 at large quantities), I had bought HM-11 for the ballbot. However, I decided that I’d get the ballbot working first with the RN42 (which I later replaced with a HC-06).
So previously, the ballbot would attempt to stay at the same spot. Sure it worked, but it was very difficult to implement remote control. My only attempt of remote control involved sending the target coordinates over bluetooth to the ballbot. This meant that I was only really controlling the target position of the robot, not the target velocity.
So a few weeks ago I managed to get my hands on a Sanyo PLC-WXU700A for free. I tried getting it to work but the warning light would light up and the projector would just shut down. I was pretty sure it was fixable but I didn’t really need a projector anyway so I left it in my room for disassembly in the future.
Well, today was the day.
So I’ve finally managed to get the robot balancing well enough to be confident to push it around on tiles and not be afraid of it falling. The derivative term of the position controller seems to be helping a lot.
But obtaining the derivative was not fun. Over the past day or so, I’ve found out that the positional output calculated from the encoders was horrendous, causing the robot to vibrate weirdly. Since then I’ve had a look at the output, and am now using a complementary filter.
So I’ve been using the RN42 bluetooth module (sold as the bluesmirf silver breakout from SparkFun), and was experiencing issues was experiencing issues with the module crashing whenever the data rate got moderately high. I was sending around 50 bytes of data from the module to the computer at around 200 Hz. The RN42 simply couldn’t cope and would stop transmitting data, though remain connected, after around two seconds. I even increase the baud rate up to the maximum of 230400 BPS and still did not see major improvements.
After more hours of tubing I decided that one of the biggest problems of the Ballbot was the hard and bouncy ball. So now, I’ve moved to using an old and deflated basketball that is rounder and dampens the vibrations of the wheels. Preliminary results are promising.
Merry Christmas everyone!
So the 18650 battery holders finally arrived yesterday. By drilling a few holes into the acrylic frame and battery holders, the holders could be securely screwed onto the robot.
Technically I did this last Saturday, but I was too lazy to upload the video with my ridiculously slow internet.
Anyway, here it is: the ballbot playing Pachelbel’s canon (AKA Canon in D) with it’s motors by changing the PWM frequency for the motor controllers! Only the first dozen or so bars are played since this is one of my earlier revisions of the program.
For any 3 wheeled robot with wheels mounted at with velocities then
where and are the x and y components of the robot’s velocity (relative to the robot), is the radius of the circle made by the wheels and is the robot’s angular velocity. This is implemented in my omnidrive library which is used by the PiBot and also the ballbot.
According to the InvenSense website:
The MPU-9250 is a System in Package (SiP) that combines two chips: the MPU-6500, which contains a 3-axis gyroscope, a 3-axis accelerometer, and an onboard Digital Motion Processor™ (DMP™) capable of processing complex MotionFusion algorithms; and the AK8963, the market leading 3-axis digital compass.
So finally the PCBs arrived yesterday afternoon and I immediately got to work this morning. Not having access to a reflow oven or hot air station certainly wasn’t helpful when soldering the 0603 surface mount components, especially WITHOUT TWEEZERS!
One of the PiBots with a spare PCB on the left
*For those that don’t know, my team represented Australia in the Robocup Junior International competition in Hefei, China, in July. It’s basically a robotics soccer competition with a small ball emitting pulsed IR. We placed 8th individually and 1st in the superteam competition, winning the finals 1:0 thanks to our camera vision.
Just some pictures of when assembling the chassis:
Without the 3d printed supporters, the acrylic mount (connected to 4 screws) is unlikely to sustain the torque applied from the motor.
So with a few modifications to the PCB design, here’s what I’m sending out for production.
So after spending a long time over the past two days designing the PCB of the ballbot, I realise I’m missing something.
I’m missing wireless communication! I’m intending to add NRF24L01+ as well as a bluetooth module, but as you can see, I’ll probably need a separate board. It’s already very hard to find space to add a few extra pins.
If you don’t know, I’ve been programming soccer playing robots for three years now to compete in Robocup open soccer. I’ve also been heavily involved in the PCB and hardware design of the robots.
Our website was once nonterminating.com but is now pi.bbcrobotics.org. Since competing in China, I’ve tried making various posts on the team website, but it seems there are issues with linkage to resources from the old site. As I’m not the site maintainer I have no clue how to fix it.
Anyway, all our code is now open source. Some of the libraries may be very useful.
The ballbot is my latest project. The name was first coined by CMU in the early 2000s when they made the first “ballbot.” Till this day, the CMU ballbot remains one of the best, if not the best, ballbot alongside the Rezero (designed by a few undergraduate students at ETH Zürich) and BallIP (Tohoku Gakuin Uni).
So I first came across when the Embrace watch was launched on Indiegogo. Essentially by monitoring the resistance across the skin of a person, it is able to reliably detect seizures. Yes, the majority of seizure related deaths have causes that are unfortunately unknown and “just happen” (SUDEP), but even the slightest probability of someone alone having a seizure at the wrong place at the wrong time (such as a flight of stairs) can be extremely worrying for families. Various attempts and products have existed on the market utilising accelerometers/gyros to determine the event of seizures and message loved ones, but they often give off false detections and they require the epileptic to have clonic seizures (i.e. jerking).
When I heard that my maths assignment would be in part, about calculating the coefficient of air resistance of an object with and without a parchute (i.e. comparing the two), I couldn’t help but extend the assignment a bit further.
So instead of uploading gigabytes of videos, here’s one of the best goals we scored in the competition.
In case you didn’t get that, here’s a side on view that starts a little bit earlier.
See how the robot turned towards the goal? That’s all thanks to the CMUCAM5 camera on the robot tracking the yellow goal.
If there’s one thing that’s popular these days, it’s quadcopters, and one of the obstacles in making a quadcopter is making it balance by obtaining roll and pitch. A simple google search will flood you with information on simple complementary, Kalman, Mahony and Madgwick filters. But what happens when you want yaw? After a bit of searching online and complementary filters (which were good enough for my application of a omnidirectional four wheeled robot), I couldn’t find a single source pointing to how to fuse gyro and magnetometer data together, and so I endeavored to approach the task from scratch. Currently, I’m using a LSM9DS0 but this should apply to all 9DOF imu’s.
Perhaps the best explanation of the complementary filter can be found here [Update. Link doesn’t work but should still be accessible via waybackmachine] which is a must read.