Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  6 4894
Installasjon av Ubuntu 16.06 ved siden av Windows (dual boot)

Først må du frigjøre litt plass: ;
1) windowsknapp+x -> disk management
2) Inne i disk management velger du hovedpartisjonen og høyreklikker -> shrink volume (minst 8 gb, ikke nødvendig med mer enn 30gb for uproblematisk å gå gjennom basics.

Installasjons USB:
1) Last ned ISO (øverste, x64): http://no.releases.ubuntu.com/16.04/
2) Last ned usb-installer https://www.pendrivelinux.com/univer...easy-as-1-2-3/
3) Skriv ISO over på USB
3.1) *Valgfritt* - Google Macrium for egen oppstartsmeny hvor du kan velge mellom oeprativsystem på en smidig måte.*
4) Boot fra USB (ved oppstart trykk F2 eller F10 eller hvaenn din PC behøver. Det vitkige er at du får bootet fra disk.
5) "Install Ubuntu alongside ..." -> nå installerer du ubnutu på den unallocated partition du laget i sted.

Valgfritt
Macrium er en god måte å sørge for at du får velge operativsystem på en smooth mtåe ved oppstart. Husker ikke i hodet hvordan det var man installerte det og jeg personlig har ikke noe problem med å måtte bruke "restart now" under "reset this PC" for å komme til UEFI menyen og boote ubuntu.

[b]Installasjon av Robot Operating System Kinetic Kane B]

ctrl+alt+t ->Åpner terminal

"$" betyr terminal input. Så når jeg skriver:
"$ gedit" så betyr det at du åpner en terminal med ctrl+alt+t, skriver "gedit autoinstall.sh" og trykker på enter.

************COPYPASTE*********

Kode

#!/bin/bash  
sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'4
sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
sudo apt-get update
sudo apt-get install ros-kinetic-desktop-full
sudo rosdep init
rosdep update
echo "source /opt/ros/kinetic/setup.bash" >> ~/.bashrc
source .bashrc
sudo apt-get remove modemmanager -y
sudo apt install python-rosinstall python-rosinstall-generator python-wstool build-essential python-catkin-tools openssh-server openssh-client openssh-known-hosts
mkdir -p ~/freak_ws/src && cd freak_ws
catkin init
catkin build 
echo "source ~/freak_ws/devel/setup.bash" >> ~/.bashrc
roscd
cd ../src
catkin_create_pkg maks_noob_pkg roscpp rospy std_msgs
cd maks_noob_pkg/src
***********COPYPASTE SLUTT******
$ chmod +x autoinstall.sh
$ ./autoinstall.sh

Nå skal du befinne deg inne i workspacen "freak_ws" og du har akkurat laget pakken "maks_noob_pkg"

Neste steg er å lære seg de helt grunnleggende funksjonene som gjør ROS til den eneste måten konkurransedyktig robotikk i overskuelig fremtid kan utvikles rundt.,

"Pfft, robotikk er ikke noe for meg", tenker mange. Men dette er langt mer enn en robot-greie. Fra pulsovervåkning på sykehus til dataanalyser og computervision.

Oh, btw, du installerte akkurat OpenCV og en haug med andre godbiter i samme slengen

Skrive en minimal node'

Detter litt stiig - ingenting mer er nødvendig for å skrive et fullverdig, selvstendig "program" som snakker med systemet forøvrig. Denne noden er helt minimal og teller bare oppover med en usignet integer som melding.

Lagre som: minimal_meldingssender.cpp

Kode

#include <ros/ros.h>
#include <std_msgs/UInt8.h>

int main(int argc, char** argv)
{
  ros::init(argc, argv, "tb_freaktalk_node");
  ros::NodeHandle nh;

	ros::Publisher teller_heltall_pub = nh.advertise<std_msgs::UInt8>("/freaktalk/teller_heltall",10);

	std_msgs::UInt8 teller_heltall_msg;
	ros::Rate rate(10);
	while(ros::ok()){
		teller_heltall_msg.data += 1;
		teller_heltall_pub.publish(teller_heltall_msg);
  	rate.sleep();
  	ros::spinOnce();
	}
  return 0;
}
De andre "standard meldingene"

Vet ikke hvor fordøyelig dette er så langt, jeg må løpe til møte med behandleren min. Krysser fingrene for innleggelse asap zulu, men vedder på at ingenting er skjedd siden sist.... Her er i alle fall en tilsvarende node som sender ut en av hver av de vanlige meldingene.

Verdt å merke seg er at alle trenger det samme:

En "Publisher" som er ansvarlig for å sende meldingen.
Selve meldingen som det er lett å glemme at holder informasjonen i ".data".

Kode

#include <ros/ros.h>
#include <std_msgs/String.h>
#include <std_msgs/Float64.h>
#include <std_msgs/Float32.h>
#include <std_msgs/Empty.h>
#include <std_msgs/Bool.h>
#include <std_msgs/UInt8.h>

int main(int argc, char** argv)
{
  ros::init(argc, argv, "tb_freaktalkmulti_node");
  ros::NodeHandle nh;

	ros::Rate rate(10);

	ros::Publisher tekst_pub 					= nh.advertise<std_msgs::String>("/freaktalk/skriver_string",10);
	ros::Publisher teller_64_pub			= nh.advertise<std_msgs::Float64>("/freaktalk/teller_64",10);
	ros::Publisher teller_32_pub 			= nh.advertise<std_msgs::Float32>("/freaktalk/teller_32",10);
	ros::Publisher teller_heltall_pub = nh.advertise<std_msgs::UInt8>("/freaktalk/teller_heltall",10);
	ros::Publisher sannhet_pub 				= nh.advertise<std_msgs::Bool>("/freaktalk/sannhet",10);
	ros::Publisher tomhet_pub 				= nh.advertise<std_msgs::Empty>("/freaktalk/tomhet",10);

	std_msgs::String tekst_msg;
	std_msgs::Float32 teller_64_msg;
	std_msgs::Float64 teller_32_msg;
	std_msgs::UInt8 teller_heltall_msg;
	std_msgs::Bool sannhet_msg;
	std_msgs::Empty tomhet_msg;


	while(ros::ok()){

		tekst_msg.data = "enkommanull";
		teller_64_msg.data = 1.0;
		teller_32_msg.data = 1.0;
		teller_heltall_msg.data = 1;
		sannhet_msg.data = false;

		tekst_pub.publish(tekst_msg);
		teller_64_pub.publish(teller_64_msg);
		teller_32_pub.publish(teller_32_msg);
		teller_heltall_pub.publish(teller_heltall_msg);
		sannhet_pub.publish(sannhet_msg);
		tomhet_pub.publish(tomhet_msg);

		rate.sleep();
		ros::spinOnce();
	}
  return 0;
}
Bygging av nodene

Det kan være veldig avskrekkende å klikke inn på CMakeLists.txt .

Det trenger ikke være så vanskelig:

Kode

cmake_minimum_required(VERSION 2.8.3)
project(maks_noob_pkg)

find_package(catkin REQUIRED COMPONENTS
  roscpp
  rospy
  std_msgs
)

include_directories(
# include
  ${catkin_INCLUDE_DIRS}
)

add_executable(freak_minimal_meldingssender_node src/minimal_meldingssender.cpp)
target_link_libraries(freak_minimal_meldingssender_node ${catkin_LIBRARIES} )

add_executable(freak_standard_meldinger_node src/standard_meldinger.cpp)
target_link_libraries(freak_standard_meldinger_node ${catkin_LIBRARIES} )
voila - nå skal du kunne skrive "catkin build" og kompilere.

For å kjøre., skriv "rosrun maks_noob_pkg freak_standard_meldinger_node"

Husk at autocomplete er din beste venn. Mash tab for harde livet when in doubt.

2stk slurvefeil:

std_msgs::Float32 teller_64_msg;
std_msgs::Float64 teller_32_msg;

---skal selvfølgelig være:
std_msgs::Float32 teller_32_msg;
std_msgs::Float64 teller_64_msg;


***********Denne glemte jeg i CMakeLists.txt (Insert rett over første "add executable"***********
catkin_package(
INCLUDE_DIRS include
)
***********

Topics som er hva vi holder på med her, er ryggraden til ROS. Alle IMU'er, aktuatorer (servoer), lasere, sonarer, kameraer ertc publiserer kontinuerlige strømmer av data. Disse kan vi "huke fatt i" gjennom callbacks. Det som forvirrer med begrepet ROS er at det ikke er et operativsystem, det er en kommunikasjonsprotokoll først og fremst. Det er et verktøy som gjør det mulig å integrere alle slags forskjellige komponenter, det være seg hardware, software eller grensesnittet imellom i samme standardiserte format.

Topics verktøy:
Rostopic list (lister forskjellige topics)
rostopic pub <topic> <meldingstype> <melding> (sender enkeltmelding til topic)
rostopic echo <topic> (lytter til topic)
rostopic hz <topic> (estimerer frekvens til topic>
rostopic bw <topic> (estimerer båndbredde til topic>
rostopic info <topic> (opplyser om hvem som publiserer og hvem som subscriber til topics)

Services
Dette er mye det samme som topics, men disse er "on demand".

Actions
Dette er som services, men for handlinger som skjer over et lengre tidsrom. Eksempler på actions er å forflytte en mobil plattform fra punkt A til punkt B. Actions har feedback, result, status og muligheten for å preempte - gitt at disse implementeres.

Jeg tror det er pedagogisk sett hensiktsmessig å styre unna services og actions så tidlig. Si fra om noen er uenig.

Det er flere fundamentale elementer som må forstås.

URDF - Universal Robot Description File. Som navnet tilsier er dette et standard format å beskrive en robot med så mange ledd, aktuatorer, frihetsgrader og sensorer som en måtte ha behov for. Disse genereres som regel av xacro.py makroer i XML-format. Det er denne magien som gjør at systemet mitt vil kunne integrere manipulatorer (robotarmer) akkurat så fort som hardwaren lar seg bygge. Så fort alt er korrekt satt opp vil generiske algoritmer sørge for at rykende ferske, uprøvde komponenter som ellers ville hatt 1 år igjen på testbenken umiddelbart er klar for operasjon i henhold til beste praksis.

Transform-tre - Hvordan kan det å beskrive et system gjøre det mulig å koordinere utallige tilstander der sensorer måler på kryss og tvers av hverandre - gjerne i bevegelse både relativt til omgivelsene og relativt til hverandre? Alle som har jobbet med transformasjonsmatriser vet hvilket helvete det fort blir. Den tiden er helt forbi. Det er vel egentlig dette som muliggjør utnyttelsen av URDF til koordinering av komplekse manipulatorer og muligheten til å bruke generisk sanntidsplanlegging. Så lenge systemet er definert korrekt vil tilstanden buffres slik at alle referanserammer kan løses relativt til hverandre med nøyaktighet ned til både 3 og 5 desimaler; med andre ord så kan alle data fra alle referanserammer transformeres hvor som helst. Mens jeg brukte 7.5 studiepoeng verdt av innsats på å stable transformasjonsmatriser oppå hverandre og trodde jeg lærte meg noe nyttig, kan jeg nå løse uedenlig mye mer komplekse utfordringer med noen standardiserte setninger.

Navigation Stack - Å forflytte en base fra A til B vil normalt sett kreve inngående kompetanse innen path planning, optimaliserte søk og mye prøving og feiling. Nå er det eneste stedet jeg ser Djikistra eller A* paramteret som kan settes til "true" or "false". Alt er integrert i en helhetlig løsning som brukes eksempelvis i moderne lagerbygg av deres automatiserte arbeidere.

CV-bridge - alle kamerastrømmer kan direkte anvende hele OpenCV's funksjonalitet. For ikke å snakke om klassifisering gjennom eksempelvis TensorFlow. Ikke så utrolig i seg selv; men ta en titt på simplisiteten og modulariteten over. En ting er å få tak i informasjon, en annen ting er å anvende den på rett sted.

Octomap - 3D sannsynlighetsmodellering av omgivelsene med utrolig effektiv utnyttelse av minnet.

Moveit - 3D motion planning som brukes bredt i industrien til operasjon av robotarmer og annet komplekst utstyr.

Gazebo - DARPA's geniale simulator som integreres sømløst med ROS.

......Tenkte dette kunne bli en hit, men slår meg at dette strengt tatt ikke er så veldig fordøyelig. Kan ikke eventuelle interessenter melde fra om jeg skal fortsette med dette? Tror det var nok en dårlig idé.
Sist endret av Jonta; 10. januar 2020 kl. 18:22. Grunn: Formatering
Artig lesning-hade ikke hørt om ROS før. Noe man kan bruke sammen med raspberry pi kanskje?
Sitat av villniss Vis innlegg
Artig lesning-hade ikke hørt om ROS før. Noe man kan bruke sammen med raspberry pi kanskje?
Vis hele sitatet...
Så absolutt!

Hadde faktisk tenkt å bevege meg dit relativt kjapt da det er den ene hardwareplattformen det er mange som har. Ferdig installert sd-img finner du her.

https://medium.com/@rosbots/ready-to...v-324d6f8dcd96

Har du 1 kamera og to servoer kan vi enkelt lage et system som følger ansikter, f.eks.

...Eller vi kan sende bildestrømmen live til PC for klassifisering med AI (forhåndstrente modeller såklart). Både YOLO og TensorFlow er relativt lavterskel.
Sist endret av Tøffetom; 10. januar 2020 kl. 23:18. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Artig! Er ikke akkurat bevandret innenfor emnet, men elektronikk, prototypeplattformer (arduino, beaglebone ol.) har blitt mer og mer en hobby kombinert med utvikling og PC-interessen.

Har du noen andre forslag til bruksområder? Jeg mangler muligens et brukbart kamera for å få til dette, har ikke til rpi'en, men har jo riktignok noen usb-kameraer.

Neste læremål her er å sette seg noe mer inn i MQTT, få opp broker og et fornuftig system for å ta imot en del data fra noen miljøsensorer, men det hadde vært artig å fått til noe gøy med et kamera!
Sitat av rogerrask Vis innlegg
Artig! Er ikke akkurat bevandret innenfor emnet, men elektronikk, prototypeplattformer (arduino, beaglebone ol.) har blitt mer og mer en hobby kombinert med utvikling og PC-interessen.

Har du noen andre forslag til bruksområder? Jeg mangler muligens et brukbart kamera for å få til dette, har ikke til rpi'en, men har jo riktignok noen usb-kameraer.

Neste læremål her er å sette seg noe mer inn i MQTT, få opp broker og et fornuftig system for å ta imot en del data fra noen miljøsensorer, men det hadde vært artig å fått til noe gøy med et kamera!
Vis hele sitatet...
ROS er perfekt for å ta imot og strukturere datastrømmer fra sensorer. ROS har noe som kalles "rosbag"; såkalte "bagfiles" som lagrer de sammenflettede dataene som rådata for senere avspilling.

Ved å bruke noe som kalles "Rosserial" kan selv lavnivå mikrokontrollere som Arduinoer programmeres til å sende meldinger på ROS sitt "språk". Jeg ville ikke gjort dette i miljøsensor sin ende, men på mottakersiden kan du enkelt konvertere inkommende data, som ofte er løst på lite kompatible måter, til den standardiserte kommunikasjonsprotokollen ROS impliserer.

Typisk eksempel på dette er konvertering av "strings" - helvete jeg er helt på bærtur, fått i meg noe GBL. Svarer deg i morgen.
Interessant, veldig og! Nyt kvelden, ser frem til mer svar, samt søke og lese litt i morra.

Natta!
https://www.youtube.com/watch?v=QzafMWj3yRc

Dette er et greit eksempel på både rosbag, transformasjonstre og URDF.

Det du ser er rådata i sanntid som ikke er prosessert på noen måte. En drone har en påmontert servo som har en 3D laserscannner opp ned festet på enden. Orienteringen til dronen måles av IMU-sensor ombord. Vinkelen mellom grunnlinjen og servoen rapporteres omtrent 100 ganger i sekundet. Ut ifra staten til aktuatoren brukes modellen av systemet (URDF'en) til å transformere punktene som kommer fra sensoren til en global referanse. Akkurat disse sekundene tiltes servoen fra -M_PI/2 -> +M_PI/4 eller noe sånt.

Faktisk så er det en høykvalitets IMU sensor (Xsens MTI til 4000,-, du får standard IMU til en 50-lapp) montert i samme orienterting som sensoren i seg selv. Tanken var at det ville bli nødvendig for nøyaktighet. Det som viser seg ved gjennomgang av datastrømmene er at det faktisk er høyere nøyaktighet fra systemt beskrevet over enn fra IMU'en direkte. Fra et mekanisk-ingeniør-perspektiv er det forbamna imponerende.

Det er vanskelig å se hva som faktisk blir scannet. Til høyre ser du havnen like ved småpudden. Det er med andre ord snakk om et område med over 50 meter i radius som scannes med 300.000 punkter i sekundet. Alle transformeres i sanntid og proesesseres i flere sekvenser når systemet kjører. Jeg klarer ærilg talt ikke forstå at det er mulig.

https://www.google.com/maps/place/Vi...71!4d5.3292004
Sist endret av Tøffetom; 11. januar 2020 kl. 02:04. Grunn: Automatisk sammenslåing med etterfølgende innlegg.