There was a scarcity of entries within the tablebot competitors shortly earlier than the registration window closed for RoboGames 2023. To ensure the competition could be held, I entered a robotic. Then I needed to construct one.
What’s a tablebot?
A tablebot lives on the desk. There are three “phases” to the competitors:
- Part I: Construct a robotic that goes from one finish of a desk to the opposite and again.
- Part II: Have the robotic push a block off the ledge of the desk.
- Part III: Have the robotic push the block right into a shoebox mounted on the finish of the desk.
There’s additionally an unofficial Part IV – which is to fall off the desk and survive. I didn’t try this part.
Nearly all of tablebots are fairly easy – a few sonar or IR sensors they usually type of wander across the tabletop in hopes of finishing the totally different phases. My tablebot is decidedly totally different – and it paid off because the robotic gained the gold medal at RoboGames 2023.
Robotic construct
All the robotic is constructed of 3D printed components and random issues I had readily available.
I’ve had a kind of $99 LD-06 lidars sitting round for some time, and determined this was an important mission to apply it to. I used a Dynamixel AX-12 servo to tilt the laser so I can discover the desk, the dice, or the purpose.
The entire code runs on an STM32, on my customized Etherbotix board which was designed for my Maxwell robotic plenty of years in the past. The robotic makes use of differential drive with some 30:1 12V gear motors, which have been bought from Lynxmotion in 2008 and utilized in numerous fireplace combating robots over time.
A set of small digital Sharp IR sensors are used as cliff sensors. These will be moved up or all the way down to calibrate for various desk surfaces utilizing a pair of adjustment screws. Whereas the sensors are very correct and cease the robotic, they don’t see far sufficient forward when going at full velocity, and so I additionally use the laser to detect when the desk edge is approaching.
Part 1 Software program
Part 1 is fairly straight ahead – and largely based mostly on useless reckoning odometry:
- The laser is angled downwards on the lookout for the desk. That is carried out by projecting to the scan to 3D factors, and filtering out something not in entrance of the robotic at roughly desk peak. When the desk disappears (variety of factors drops too low), we cut back our most velocity to one thing that’s protected for the cliff sensors to detect.
- Whereas the laser sensors search for the top of the desk, the robotic drives ahead, and a easy suggestions loop retains the robotic centered on the desk utilizing odometry.
- When the cliff sensors finally set off, the robotic stops, backs up 15 centimeters, after which turns 180 levels – all utilizing useless reckoning odometry.
- The utmost velocity is then reset and we take off to the opposite finish of the desk with the identical habits.
Part 2 Software program
The actions of Part 2 are mainly the identical as Part 1 – we drive ahead, staying centered with odometry. The velocity is a bit decrease than Part 1 as a result of the laser can also be on the lookout for the block:
- The laser scan is projected to 3D, and we filter out any factors which can be a part of the desk based mostly on peak. These remaining factors are then clustered and the clusters are analyzed for dimension.
- If a cluster is an effective candidate for the block, the robotic flip in the direction of the block (utilizing, you guessed it, useless reckoning from odometry).
- The robotic then drives in the direction of the block utilizing a easy management loop to maintain the heading.
- As soon as the block is arrived at, the robotic drives straight till a cliff sensor journeys.
- At that time, the robotic stops the wheel on the facet of the tripped cliff sensor and drives the opposite wheel very slowly ahead in order that we align the entrance of the robotic with the sting of the desk – making certain the block has been pushed off the desk.
Part 3 Software program
The ultimate part is essentially the most advanced, however not by a lot. As with the sooner phases, the robotic strikes down the desk discovering the block:
- Not like in Part 2, the robotic really approaches a pose simply behind the block.
- As soon as that pose has been reached, the robotic tilts the laser again to degree and finds the purpose.
- The robotic then turns in the direction of the purpose in the identical method it first turned in the direction of the block.
- The robotic then approaches the purpose utilizing the identical easy management loop, and within the course of finally ends up pushing the block to the purpose.
The entire software program for my Tablebot is availble on GitHub.
Robogames video
Jim Dinunzio, a member of the Homebrew Robotics Membership, took a video in the course of the precise competitors at Robogames so you possibly can really see the profitable set of runs:
Visualization
To make growth simpler, I additionally wrote a Python GUI that renders the desk, the robotic odometry path, the laser information, and detected targets and cubes.
Enjoyable with math
Alongside the best way I really ran right into a bug within the ARM CMSIS DSP library. I used the arm_sin_cos_f32()
perform to compute my odometry:
arm_sin_cos_f32(system_state.pose_th * 57.2958f, &sin_th, &cos_th);
system_state.pose_x += cos_th * d;
system_state.pose_y += sin_th * d;
system_state.pose_th = angle_wrap(system_state.pose_th + dth);
This perform takes the angle (in levels!) and returns the sine and cosine of the angle utilizing a lookup desk and a few fascinating interpolation. With the visualization of the robotic path, I observed the robotic odometry would sometimes soar to the facet and backwards – which made no sense.
Additional investigation confirmed that for very small damaging angles, arm_sin_cos_f32
returned large values. I dug deeper into the code and located that there are a number of totally different variations on the market:
- The model from my older STM32 library, had this explicit concern at very small damaging numbers. The identical bug was nonetheless current within the official CMSIS-DSP on the arm account.
- The model within the present STM32 library had a repair for this spot – however that repair then broke the perform for a complete quadrant!
The difficulty turned out to be fairly easy:
- The code makes use of a 512 component lookup desk.
- For a given angle, it has to interpolate between the earlier and subsequent entry within the desk.
- In case your angle fell between the 511th entry and the following (which might be the 0th entry attributable to wrap round) then you definitely used a random worth within the subsequent reminiscence slot to interpolate between (and to compute the interpolation). At one level, this resulted in sin(-1/512) returning outrageous values of like 30.
With that bug fastened, odometry labored flawlessly afterwards. Because it turned out, I had this similar perform/bug current in some brushless motor management code at work.
Robogames wrap up
It’s superior that RoboGames is again! This little robotic gained’t be making one other look, however I’m beginning to work on a RoboMagellan robotic for subsequent yr.
Michael Ferguson