Category:ICS0023 Robotics: Difference between revisions

From ICO wiki
Jump to navigationJump to search
 
(13 intermediate revisions by 2 users not shown)
Line 83: Line 83:
==Maze solver==
==Maze solver==


===Members: Allar Vendla, Henri Paves, Madis Võrklaev, Andreas Porman===
===Members: Allar Vendla, Andreas Porman, Henri Paves, Madis Võrklaev ===
 
Allar & Andreas - software guys
 
Henri - 3D modeling
 
Madis - electronics, hardware and project management
 
===GitHub: [https://github.com/allavett/mazeRunner2017 see here]===


===Rules: [https://robotex.ee/wp-content/uploads/2017/07/robotex-lab%C3%BCrindi-reeglid-EST.pdf download here]===
===Rules: [https://robotex.ee/wp-content/uploads/2017/07/robotex-lab%C3%BCrindi-reeglid-EST.pdf download here]===
Line 92: Line 100:
* walls are made of 18cm x 18cm blocks
* walls are made of 18cm x 18cm blocks


====Hardware needed:====
====Hardware used:====
* ESP8266 / Arduino?
* [https://store.arduino.cc/arduino-yun Arduino YUN]
* suitable motors (Fauhalber, Maxon, STEPPER)? + wheels
* [http://www.nmbtc.com/pdf/motors/standard_hybrid/17PM-K.pdf Nema17 bipolar stepper motors] w. dual [http://www.st.com/content/ccc/resource/technical/document/datasheet/09/80/6c/ac/79/b2/47/c4/CD00000090.pdf/files/CD00000090.pdf/jcr:content/translations/en.CD00000090.pdf L6204 drivers]
* power supply
* 19V Makita Li-Ion battery
* ultrasonic or IR sensors?
* TK0446 DC-DC step-up converter to get 30V for steppers
* wireless UART for Arduino for live log? HC-12?
* [http://www.micropik.com/PDF/HCSR04.pdf HC-SR04] ultrasonic sensors for distance
* 3D printed frame? Could also be cut from plastic.
* [http://www.produktinfo.conrad.com/datenblaetter/150000-174999/153775-da-01-en-HALL_SENSOR_TLE_4935L.pdf TLE4905L] HALL effect sensors for position tracking
* 3D printed frame.


====Software problems:====
====Software problems:====
* maze emulation for SW testing
* maze emulation for SW testing - Allar
* should it turn at first chance? or go as far as possible, then come back and try the first turn on its way back?
* should it turn at first chance? or go as far as possible, then come back and try the first turn on its way back?
* recursive function for learning
* recursive function for learning
====Progress & thoughts:====
We made a first simple prototype with a [https://www.oomipood.ee/product/rob_2wd_1_robotauto_aluskomplekt_2wd_1_rattad_mootorid_kinnitused?q=robot bought chassis], Arduino Uno, 3x ultrasonic sensors and optical RPI-579 sensors for wheels. As it quickly turned out, it was really hard to get the driving and turning right without seeing the sensors' realtime data. So we needed a way to see the Arduino's serial monitor wirelessly.
At the moment there's 2 good choices for a controller that has a wireless on board - Arduino YUN and ESP32. YUN is much more expensive, ESP seems more complicated to program. As I just happen to have a YUN lying around, it's our current choice to go on with the project.
UPDATE 16.10
We have a second prototype with 3D printed chassis. All the hardware should be the same that will be used on a final version. Henri accidentally drew the chassis a bit too big, so for the final version we need to print a new chassis.
At the moment we're able to read the HC-SR04 and Hall effect sensors inside the motors and make it move as we want. The ultrasonic sensors aren't the best choice, because they are slow, but they're easy to use.
The next steps would be building a real life maze with some turns to calibrate the moving and sensor reading in order to get it drive straight, turn exactly 90 degrees and, if necessary, adjust its position.
Some photos and videos can be seen [https://photos.app.goo.gl/ZlsJMKsiH4c502v03 here in Google Photos].
And it has a name! Jõmmu.
UPDATE 17.11
A week before competition we built a completely new unit. The main problem was that the previous one was too big, and we couldn't get it any smaller with the MAXON's motors. Madis had some NEMA17 steppers lying around, and so we decided to test them. We made an custom Arduino-shield to accomodate dual stepper drivers and all necessary connections. The PCBs were ordered from [https://www.elecrow.com/ Elecrow]. It took 8 days to get them manufactured and shipped with DHL to Estonia.
The Makita battery holder's model was found from [https://www.thingiverse.com/thing:1809114 here].
{|style="margin: 0 auto;"
| [[File:1jm.jpg|thumb|alt=Battery holder|3D printed battery holder.]]
| [[File:2jm.jpg|thumb|alt=Battery holder|3D printed battery holder.]]
| [[File:3jm.jpg|thumb|alt=Frame w.motors|3D printed frame with motors.]]
|}
{|style="margin: 0 auto;"
| [[File:4jm.jpg|thumb|left|alt=Driverboard|Custom driverboard.]]
| [[File:6jm.jpg|thumb|alt=Assembled|Assembled with battery.]]
| [[File:7jm.jpg|thumb|alt=Assembled|Assembled with battery.]]
|}
UPDATE 26.11
CONCLUSION (what we learned):
Madis:
* think and think again to get already the first prototype with correct measures and usable hardware
* surf around and see what others have done ([http://greenye.net/Pages/Micromouse/Micromouse2015-2016.htm a real robomouse])
* create deadlines for bigger stages of the project
* when making PCB design, double check that all power and GND traces are connected and they have decent cross-section
* test all the hardware functions before giving it to programmers
* make hardware components modular, so any component can be easily replaced if necessary
* make sure to have enough spares for every component
Henri:
* In electronics, a significant amount of effort is needed simply to suppress hardware noise
* A coding error might quite literally send the hardware up in flames
* Hardware may produce spikes and weird signals, especially during booting/resets
* As such, software needs to be able to handle any errant signals that the hardware may send
* Brainstorming your for your own unique ideas is a great way to learn, but not an optimal way to win a competition
* Never develop hardware and software simultaneously

Latest revision as of 16:25, 28 November 2017


Intro

The Robotics course is intended to provide 6 ECTS for participating in the Robotics Club activities. From September until November of 2017 the main focus is to get two basketball robots and four sumorobots ready for Robotex 2017.

Basically attend lectures, pick any of the suggested tasks/projects, confirm with Lauri and earn your ECTS.

Lectures/meetings

For September four lectures/meetings will take place:

  • 7. September 14:00-15:30 room 410 in College building - Introduction of Robotics Club, it's equipment, capabilities and resources. Recap of last year, take a look at running projects.
  • 14. September 14:00-15:30 room 410 in College building - Image recognition, OpenCV, Python, video capture/playback
  • 21. September 14:00-15:30 room 410 in College building - Microcontrollers, take a look at Arduino, ESP32 and their capabilities
  • 28. September 14:00-15:30 room 410 in College building - Powering circuits, work safety, measuring tools, form teams for Robotex 2017.

After September students are expected to with their group on a weekly basis at Robotics Club (room 412) to work on their project, for easier synchronization there shall be pizza on Thursdays 18:00 :)

24-26. November - Qualify at Robotex with your team's robot

Tasks & projects

Basketball robot source and relevant issues: https://github.com/eik-robo/zoidberg/issues

  • K-means clustering for image recognition
  • Pipeline latency measurement
  • Basketball throwing mechanism design and assembly

Sumorobot source and relevant issues: https://github.com/eik-robo/sumoesp

  • Conduct workshops for children
  • Web interface development
  • Make sumo programmable in a new programming language

Learn about gadget, publish howto and conduct workshop

  • WiFi Pineapple NANO
  • Bash Bunny
  • USB Rubber Ducky
  • LAN Turtle
  • HackRF
  • Proxmark 3
  • Yubikey

Robotics club PR:

  • Maintain homepage, write and publish stories
  • Create page at hackerspaces.org
  • Find sponsors

Other

  • Set up inventory management/tracking


For fun


Teams

Teh space probe

Members: Mikus, Frank

Hardware missing: none?

Zoidberg & Nibbler vol2

Members: Marek, Madis, Taivo, Fred, Mohanad

Hardware needed: ?

Maze solver

Members: Allar Vendla, Andreas Porman, Henri Paves, Madis Võrklaev

Allar & Andreas - software guys

Henri - 3D modeling

Madis - electronics, hardware and project management

GitHub: see here

Rules: download here

Arena:

  • robot max diameter 16cm
  • 3mm timing beam @ 3cm from ground
  • walls are made of 18cm x 18cm blocks

Hardware used:

Software problems:

  • maze emulation for SW testing - Allar
  • should it turn at first chance? or go as far as possible, then come back and try the first turn on its way back?
  • recursive function for learning

Progress & thoughts:

We made a first simple prototype with a bought chassis, Arduino Uno, 3x ultrasonic sensors and optical RPI-579 sensors for wheels. As it quickly turned out, it was really hard to get the driving and turning right without seeing the sensors' realtime data. So we needed a way to see the Arduino's serial monitor wirelessly.

At the moment there's 2 good choices for a controller that has a wireless on board - Arduino YUN and ESP32. YUN is much more expensive, ESP seems more complicated to program. As I just happen to have a YUN lying around, it's our current choice to go on with the project.

UPDATE 16.10

We have a second prototype with 3D printed chassis. All the hardware should be the same that will be used on a final version. Henri accidentally drew the chassis a bit too big, so for the final version we need to print a new chassis. At the moment we're able to read the HC-SR04 and Hall effect sensors inside the motors and make it move as we want. The ultrasonic sensors aren't the best choice, because they are slow, but they're easy to use.

The next steps would be building a real life maze with some turns to calibrate the moving and sensor reading in order to get it drive straight, turn exactly 90 degrees and, if necessary, adjust its position.

Some photos and videos can be seen here in Google Photos.

And it has a name! Jõmmu.

UPDATE 17.11

A week before competition we built a completely new unit. The main problem was that the previous one was too big, and we couldn't get it any smaller with the MAXON's motors. Madis had some NEMA17 steppers lying around, and so we decided to test them. We made an custom Arduino-shield to accomodate dual stepper drivers and all necessary connections. The PCBs were ordered from Elecrow. It took 8 days to get them manufactured and shipped with DHL to Estonia.

The Makita battery holder's model was found from here.

Battery holder
3D printed battery holder.
Battery holder
3D printed battery holder.
Frame w.motors
3D printed frame with motors.
Driverboard
Custom driverboard.
Assembled
Assembled with battery.
Assembled
Assembled with battery.

UPDATE 26.11

CONCLUSION (what we learned):

Madis:

  • think and think again to get already the first prototype with correct measures and usable hardware
  • surf around and see what others have done (a real robomouse)
  • create deadlines for bigger stages of the project
  • when making PCB design, double check that all power and GND traces are connected and they have decent cross-section
  • test all the hardware functions before giving it to programmers
  • make hardware components modular, so any component can be easily replaced if necessary
  • make sure to have enough spares for every component

Henri:

  • In electronics, a significant amount of effort is needed simply to suppress hardware noise
  • A coding error might quite literally send the hardware up in flames
  • Hardware may produce spikes and weird signals, especially during booting/resets
  • As such, software needs to be able to handle any errant signals that the hardware may send
  • Brainstorming your for your own unique ideas is a great way to learn, but not an optimal way to win a competition
  • Never develop hardware and software simultaneously

This category currently contains no pages or media.